The Concise Guide to 


MICROSOFT 


WINDOWS 2000 DNS 


Uncommon Solutions 


for the Technical Professional 


pUe Andy Ruth & Bob Collier 


{ The Concise Guide to} 


MICROSOFT 


WINDOWS 2000 DNS 


Bob Collier and Andy Ruth 


A Division of Macmillan USA 3 
UEO 201 W 103rd Street Bob Collier 
C) Indianapolis, IN 46290 Andy Ruth 


The Concise Guide to Microsoft 
Windows 2000 DNS 


Bob Collier and Andy Ruth 


Copyright © 2000 by Que Corporation 


All rights reserved. No part of this book shall be reproduced, 
stored in a retrieval system, or transmitted by any means, 
electronic, mechanical, photocopying, recording, or otherwise, 
without written permission from the publisher. No patent lia- 
bility is assumed with respect to the use of the information 
contained herein. Although every precaution has been taken 
in the preparation of this book, the publisher and author 
assume no responsibility for errors or omissions. Nor is any 
liability assumed for damages resulting from the use of the 
information contained herein. 


International Standard Book Number: 0-7897-2335-2 
Library of Congress Catalog Card Number: 99-069109 
Printed in the United States of America 

First Printing: August, 2000 

02 01 00 4 3 2 1 


Trademarks 


All terms mentioned in this book that are known to be trade- 
marks or service marks have been appropriately capitalized. 
Que Corporation cannot attest to the accuracy of this infor- 
mation. Use of a term in this book should not be regarded as 
affecting the validity of any trademark or service mark. 


Warning and Disclaimer 


Every effort has been made to make this book as complete 
and as accurate as possible, but no warranty or fitness is 
implied. The information provided is on an “as is” basis. The 
authors and the publisher shall have neither liability nor 
responsibility to any person or entity with respect to any loss 
or damages arising from the information contained in this 
book. 


| Associate Publisher 
| Tracy Dunkelberger 


: Acquisitions Editors 


Gretchen Ganser 


| Tracy Williams 


| Development Editor 


Todd Brakke 


| Managing Editor 


Thomas F. Hayes 


Senior Editor 
Susan Ross Moore 


Copy Editor 
Sossity Smith 


| Indexer 
| Deborah Hittel 


Proofreader 


| Maribeth Echard 


| Technical Editor 
| Jim Cooper 


| Team Coordinator 
| Vicki Harding 


| Interior Designer 
Trina Wurst 


Cover Designer 


| Rader Design 


| Production 

| Ayanna Lacey 

| Heather Miller 

| Stacey Richwine-DeRome 


Contents at a Glance 


Introduction 1 

Dynamic DNS Overview and Specifications 5 
The Name Resolution Process 17 

Windows 2000 DNS Clients and Servers 33 
Preparing to Install DNS 47 

Installing DNS 73 

Post-Installation Configuration 99 
Configuring DNS Clients 123 

Exploring Resource Records 153 

Using Windows 2000 DNS As a Locator Service 173 
Maintaining DNS in Windows 2000 185 


pi 
ht © 


Growing a DNS Implementation 199 


— 
N 


Securing and Troubleshooting DNS Communications 207 
A Command-Line Utilities 243 

B Glossary 255 

Index 261 


About the Authors 


Bob Collier began his career in the computer industry programming in 
the early 1980s while on active duty in the military. He helped design, 
implement, and manage computer networks at military organizations. 
He currently is a Senior Technical Instructor at the Advanced Computer 
Education Center, School of Engineering and Applied Science, Southern 
Methodist University in San Antonio, Texas. In addition to his responsi- 
bilities as a technical instructor, Bob also administers the network at 
SMU and is the Exchange Administrator. Special areas of expertise 
include Windows NT 4.0, Windows 2000 planning and upgrade, and 
Exchange Server implementation. Bob is currently certified as an MCSE, 
MCT, MCP+I, and A+. He is pursuing Windows 2000 and MCSD certifi- 
cations as well as CCNA. Bob is also involved in consulting for small- to 
medium-size businesses in San Antonio and surrounding areas, specializ- 
ing in network design, implementation, troubleshooting, and documenta- 
tion skills for Windows NT 4.0 BackOffice networks. Bob has contributed 
to several books and online books and has done some technical editing for 
Windows NT magazine. 


Andy Ruth has been in the computer industry since the late 1970s 
when he joined the U.S. Navy and provided support of flight simulators. 
In the corporate environment, he has provided systems support for com- 
puters ranging from large mainframes to small PC networked environ- 
ments. He holds MCT and MCSE + I certifications, as well as others, and 
has written a number of other books on Microsoft products. Ruth is cur- 
rently a Program Manager at Microsoft Corporation, working with the 
Windows 2000 training curriculum, and is also a guest speaker at tech- 
nology seminars. 


Dedication 


I would like to dedicate this book most of all to my beautiful, loving wife, 
Betsie. She has endured the long, long months during the writing of this 
book and has been extraordinarily supportive during the whole process. I 
also would like to dedicate this book to my children: Hazel, Eric, Travis, 
and my new little baby girl Claudia. They also have had to endure not 
seeing me for days at a time. Thanks to my entire family for being so sup- 
portive. 


Bob Collier 
I would like to dedicate this book to Jaylene, my love, and my life. 
Andy Ruth 


Acknowledgments 


We would like to acknowledge Tracy Williams, Todd Brakke, Jim Cooper, 
Gretchen Ganser, and the entire staff at Que for their hard work, dedica- 
tion to quality, and most of all for their everlasting patience during this 
book. Without their support, this book would not be possible. 


We also would like to thank H. James Toland III for helping keep the 
quality of this book to a high standard, and Jim Loux for his contributions 
to this book. Finally, in the place of honor, thanks to M. Cook, L. Ogea, 
and B&E Phillips for their unwavering friendship and guidance. You don’t 
realize what support you provide. 


Contents 


Introduction 1 
Background, Theory, and Reference 2 
Planning and Installing 2 
Maintaining 3 
What’s in This Book 3 


1 Dynamic DNS Overview and Specifications 5 
A Brief History of DNS 5 


What’s New and Different About DNS in 
Windows 2000 6 


Internet Entities 8 

Request for Comments (RFC) 9 

The Windows 2000 DNS RFCs 11 

IETF Drafts 14 

BIND Capabilities and Compatibilities 15 


2 The Name Resolution Process 17 
The Physical and Logical Internet 18 
The DNS Architecture 19 

Domain Name Space 20 
Name Server 23 
Resolver 26 
Recursive Query 26 
Iterative Query 27 
Caching Resolutions 29 
Server Caching 29 
Client Caching 30 


3 Windows 2000 DNS Clients and Servers 33 
Zone Types 33 
Standard Zones 33 
Active Directory Integrated Zone 34 
Name Server Types 35 
Primary Name Server 35 
Secondary Name Server 36 


Contents vil 


Master Name Server 37 
Caching-Only 38 
Active Directory Integrated 38 
Reverse Lookup 39 

Installing and Configuring the DNS Service 40 
Installing the DNS Service 40 
Post-Configuration Tasks 41 
Creating a New Zone 42 

Client Resolvers 43 
Windows 2000 Clients 43 

Windows NT 4.0 Clients 44 

Windows 9x Clients 45 
Non-AD-Aware Clients 45 

Dynamic Update Configuration 46 


4 Preparing to Install DNS 47 
Planning fora DNS Deployment 47 
Namespace Planning 48 
Zones 50 
Reverse Lookup Zones 52 
Server Planning 52 
Number and Placement of DNS Servers 55 
Migrating Servers 55 
Interoperability Planning for DNS 56 
Planning a Structure 57 


Using a Previously Registered Domain Name for the Active 
Directory Root Domain 57 

Using a Subdomain of a Registered DNS Domain Name As the 
Active Directory Root Domain 58 

Use a Reserved Private DNS Domain Name for the Active 
Directory Root Domain 58 

Use of a Single DNS Name for Both Private /Internal and 
Public/External Networks 60 

Using Different DNS Domain Names for Internal / Private and 
External/Public Networks 66 


Vill Contents 


Registering a Domain Name _ 69 
Reserving a Top-Level Domain Name 69 
Registering Your Top-Level Domain 70 
Registering an in-addr.arpa Domain Name 70 


5 Installing DNS 73 
Installation of DNS 74 
Installing During Windows 2000 Installation 76 


Installing with the Windows 2000 Configure Your Server Wizard 
76 


Installing DNS with Add/Remove Programs in Control Panel 
80 


Installing DNS Using DCPROMO.exe 81 
Installing a Root Name Server 83 
Installing a Primary Name Server 87 
Installing a Secondary Name Server 89 
Installing a Caching-Only Name Server 92 
Installing an Active Directory—Integrated Name Server 94 


6 Post-Installation Configuration 99 
General Configurations Options 100 
Managing Resource Records 103 
The Hints File 109 
The “.” Zone 111 
Configuring DNS Notify 112 
DNS Notify—The Process 113 
Configuring the Notify List 115 
Configuring Start of Authority (SOA) Resource Records 116 
Adding NS Resource Records 119 
Configuring Dynamic Zone Update 119 


7 Configuring DNS Clients 123 
Windows 2000 Clients 124 
Windows 2000 DHCP Client 127 
Statically Configured Windows 2000 Client 140 
Remote Access Server Clients 141 


Contents ix 


Windows 2000 Secure Dynamic Updates 142 


Windows 2000 DHCP Clients Using a Windows NT 4.0 DHCP 
Server 147 


Windows 9.X Clients 147 


Dynamic Registration of Pointer (PTR) Resource Records for 
Down-Level Clients 148 


Dynamic Registration of Host (A) and Pointer (PTR) Resource 
Records for Down-Level Clients 149 


Other Clients 151 


8 Exploring Resource Records 153 
Format of DNS Resource Records 153 
A Resource Records 155 
AAAA Resource Records 156 
CNAME Resource Records 158 
MX Resource Records 160 
PTR Resource Records 163 
SRV Resource Records 165 
Other Resource Records 167 

HINFO Resource Record 167 
TXT Resource Record 167 
WKS Resource Record 168 


New and Experimental Resource Records 168 


9 Using Windows 2000 DNS As a Locator Service 173 
Windows 2000 Networking 173 
Workgroup 174 
Domain 175 
Dynamic Update in Windows 2000 180 
How Dynamic Update Works 180 
SRV Resource Records 182 
Updating Zone Information 183 


10 Maintaining DNS in Windows 2000 185 
Securing DNS 185 
Secure Dynamic Update 185 


Contents 


Day-to-Day Tasks 189 
Viewing the Event Log for DNS 189 
Cleaning Up Orphan Entries 191 
Configuring Automatic Scavenging 191 
Performance Monitor 193 
DNS Counters 194 
Viewing Real-Time Data 195 
Logging Data 195 
Planning for Disaster Recovery 198 


11 Growing a DNS Implementation 199 
Bigger Server Versus More Servers 199 


Advantages and Disadvantages of Single, More-Powerful 
Servers 200 


Advantages and Disadvantages of Multiple Smaller Servers 
201 


Adding Name Servers 201 

Configuring Round Robin 203 
Changing Time to Live (TTL) to Reduce Workload 205 
Modifying Start of Authority Resource Records 205 


12 Securing and Troubleshooting DNS 
Communications 207 


Securing Windows 2000 DNS 208 
Security in a Standard Zone Storage Model 211 


Multimaster Update and Enhanced Security Based on the 
Capabilities of Active Directory 212 


Default Dynamic Update Security 215 


Security Concerns When Using the DnsUpdateProxyGroup 
216 


Testing and Monitoring Your DNS Implementation 217 
Using nslookup 220 
Other Diagnostic Tools 221 
Automating Server Administration Using Dnscmd 221 
ping 223 
tracert Utility 224 


Contents 


ipconfig Utility 225 
netstat Utility 225 
nbtstat Utility 226 
Troubleshooting Windows 2000 DNS 226 
Troubleshooting DNS Clients 227 
Troubleshooting DNS Servers 230 
Troubleshooting Dynamic Updates 234 
Troubleshooting DNS Zones 236 
Interoperability Problems 238 


Zone Transfer with BIND and Other DNS Server 
Implementations 238 


Supporting Active Directory with Other DNS Server 
Implementations 239 


Interoperating Windows DNS Servers with Other DNS Server 
Implementations 239 


Using DNS on the Internet 240 
Interoperability Planning: Configuring Related Services 241 


A Command-Line Utilities 243 


Troubleshooting and Configuring DNS Through Command-Line 
Tools 243 


nslookup Command 243 
Using ipconfig to Troubleshoot DNS 247 


Using dnscmd from the Command Line to Manage Your DNS 
Servers 251 


Using Netlogon from the Command Prompt to 
Manage DNS 252 


B Glossary 255 
Index 261 


Tell Us What You Think! 


As the reader of this book, you are our most important critic and com- 
mentator. We value your opinion and want to know what we're doing 
right, what we could do better, what areas you’d like to see us publish in, 
and any other words of wisdom you're willing to pass our way. 


As an Associate Publisher for Que, I welcome your comments. You can 
fax, email, or write me directly to let me know what you did or didn’t like 
about this book—as well as what we can do to make our books stronger. 


Please note that I cannot help you with technical problems related to the 
topic of this book, and that due to the high volume of mail I receive, I 
might not be able to reply to every message. 


When you write, please be sure to include this book’s title and author as 
well as your name and phone or fax number. I will carefully review your 
comments and share them with the author and editors who worked on 
the book. 


Fax: 317-581-4666 
Email: quetechnical@macmillanUSA.com 


Mail: Tracy Dunkelberger 
Associate Publisher 
Que Corporation 
201 West 103rd Street 
Indianapolis, IN 46290 USA 


xii 


INTRODUCTION 


The Concise series is meant to provide specific information on a product or 
subject to provide you, the reader, with enough information to understand 
and implement the product or subject covered. To that end, the Concise 
Guide to Microsoft Windows 2000 DNS is meant to provide enough back- 

_ ground information, theory, and practical product information to help you 
install, configure, and maintain a Windows 2000 DNS server. 


It is expected that most of you will have a firm understanding of TCP/IP 
concepts including IP addressing and subnetting, and knowledge of name 
resolution with DNS. Unless you currently support a name server, you 
might not fully understand how DNS works, and unless you support a 
Windows 2000 network, you might not understand how DNS is used in that 
networking environment. With this book, we’ve tried to provide enough 
background information on DNS and Windows 2000 networking to allow 
you to understand the significance of the decisions you will have to make 
while installing and configuring the Windows 2000 DNS service. 


This book can be divided into three main parts: 


E Background, theory, and reference information 
@ Planning and installing 
W Maintaining 


2 Introduction 


Background, Theory, and Reference 


The first three chapters provide information about the standards that define DNS as well as 
the standards that are supported by the DNS service provided with Windows 2000. We also 
cover how DNS works, and what the major components of DNS are. 


Chapter 1 provides a brief description of the information contained in each of the chapters, 

a list of RFCs and drafts that define DNS, and some that are just being implemented in the 
newer implementations of DNS. Also covered is information on what is new to the DNS service 
provided with the Windows 2000 products. Chapters 2 and 3 explain the name resolution 
process and the role of DNS clients and servers. 


We suggest you read each of the RFCs and drafts listed in Chapter 1. Although some of those 
RFCs are obsolete, the information contained in them is still valid in providing you an under- 
standing of DNS. Where we could, we listed the ones we felt were critical for you to read to 
have a firm understanding of DNS in Windows 2000. Although we paraphrase some of the 
RFCs and drafts, the wealth of information contained in each should not be missed. 


Keep in mind that industry standards and the products we (as IT professionals) are expected 
to support are always evolving, and that security concerns and measures are in a constant 
state of change. That being said, you must browse the IETF and IANA Web sites, and join pro- 
fessional groups, such as SANS, in order to stay abreast of current technology and support 
concerns. For instance, while writing this book, RFC 2052 was made obsolete by RFC 2782. 
The changes were not significant, but RFC 2782 does define a bit more clearly the SRV 
resource record and its role in networking. 


Planning and Installing 


Chapters 4 through 7 provide the bulk of the information needed to plan a DNS installation, 
and install the DNS service provided with Windows 2000. For those not running Windows 
2000, there are several screen shots of the user interfaces used to perform the tasks detailed 
in this book. 


If you have a Windows 2000 server that can be used for test purposes, we suggest you perform 
the tasks we detail in this book and become as familiar as possible with Windows 2000. In 
Chapters 8 and 9, we attempted to provide insight into Windows 2000 networking and the role 
of DNS and SRV resource records. 


You will find that DNS is an integral part of Windows 2000 networking and a firm under- 
standing of the Windows 2000 Active Directory and LDAP will be needed to fully comprehend 
the information stored in a DNS zone. This book provides a brief introduction to Active 
Directory, but that is not the main focus. 
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Maintaining 

If you plan the installation of DNS correctly, the installation portion of the task is typically the 
easiest part, although the bulk of your time will be spent maintaining the operational DNS 
service. Chapters 10 through 12 provide the information needed to support a DNS network. 
We show you the tools available in the DNS management tool and the tools available with 
Windows 2000 that are used to maintain the Windows 2000 DNS service. We also cover the 
utilities and command-line tools available for maintaining and troubleshooting the DNS serv- 
ice as well as the name resolution process. 


vo in This Book 


Chapter 1, “Dynamic DNS Overview and Specifications,” provides an overview of whats 
new with the Windows 2000 DNS service, who makes RFC standards and how they are 
created, the RFCs used to define most RFC-compliant name servers, the RFCs relevant 
to the Windows 2000 DNS service, and finally the IETF drafts relevant to DNS in 
Windows 2000. 


W Chapter 2, “The Name Resolution Process,” covers how queries are performed and how 
the name resolution process occurs. Recursive and iterative queries will be explored and 
explained, and successful and unsuccessful caching of name resolution attempts on the 
server and client will then be covered. This chapter also explains the impact of making 
various configuration changes to your DNS deployment and what impact it will have on 
the network. 


W Chapter 3, “Windows 2000 DNS Clients and Servers,” starts with an explanation of the 
different types of DNS name servers that can be configured and how each works, and 
then covers the support offered for various DNS clients and how each interoperates with 
the Windows 2000 DNS service. 


E Chapter 4, “Preparing to Install DNS,” details the key decision points that should be 
considered before installing DNS, including planning a structure, registering a domain 
name, and registering an in-addr.arpa domain. Also covered are the differences between 
installing the DNS service as the first server up in a domain, or as an additional server. 


lm Chapter 5, “Installing DNS,” walks through the installation process. The installation 
can be accomplished by running an installation wizard, or as part of the Active Directory 
(AD) installation. This chapter provides step-by-step coverage of the installation process, 
and configuring the DNS service as a root, primary, secondary, caching-only, or AD- 
integrated name server. 


Æ Chapter 6, “Post-Installation Configuration,” covers the configuration items not specifi- 
cally covered by the installation wizard. The hints file is explored, as well as the SOA 
and NS resource records, and what impact they have on the DNS service. Configuring 
DNS Notify, delegating to subdomains, and configuring client updates to the zone are 
also covered. 


Introduction 


Chapter 7, “Configuring DNS Clients,” provides information about configuring client 
update properties, and updating various clients with newer, AD-aware client software, 
and configuring non—AD-aware clients. Also covered are configuring successful and 
unsuccessful caching properties. 


Chapter 8, “Exploring Resource Records,” provides detailed information about A, 
CNAME, and MX resource records, as well as limited information about other types of 
records that are in use, and detail what each is used for. 


Chapter 9, “Using Windows 2000 DNS As a Locator Service,” is the most useful chapter 
for the DNS aficionado. This chapter provides an overview of Windows 2000 networking, 
and details how the DNS service provides name resolution services to the network and 
replaces the WINS service as the primary network services locator mechanism. This 
chapter compares and contrasts the WINS and DNS, explains how the SRV resource 
record is employed, and details the zone update process. 


Chapter 10, “Maintaining DNS in Windows 2000,” covers the day-to-day tasks of caring 
for the DNS service, as well as controlling and securing the DNS service. Also covered 
are planning for disaster, cleaning up orphan zone entries, and using Performance 
Monitor to optimize and maintain efficient performance. 


Chapter 11, “Growing a DNS Implementation,” details the steps followed when adding 
additional replication name servers, and delegating authority to subdomains. As most 
large DNS installations will most likely have some version of BIND running as the DNS 
name service, this chapter provides information about how to integrate the Windows 
2000 DNS service into a BIND site. 


Chapter 12, “Securing and Troubleshooting DNS Communications,” provides you with 
the information needed to secure your Windows 2000 DNS installation and load your 
logical toolbox with the tools necessary to troubleshoot and support a network. This 
includes a number of command-line utilities used to update zone information for clients 
and servers, purge cache entries, and verify the operation of the DNS service. 


Appendix A, “Command-Line Utilities,” provides a summary of the basic command-line 
utilities that can be used to verify and troubleshoot DNS operations. 


Appendix B, “Glossary,” provides a definition of the terms and acronyms used in this 
book. 


DYNAMIC DNS 
OVERVIEW AND 
SPECIFICATIONS 


A Brief History of DNS 


Once upon a time (as in any good story), there was an unassuming file 
called HOSTS. The HOSTS file stored all the information needed to resolve 
a hostname to an IP address for the ARPANET, which, at the time, was the 
United States government-sponsored network that connected the military, 
government, university, and government contractors. The ARPANET used a 
flat naming structure, so it was not apparent who fit into what category. 


As the ARPANET grew, the HOSTS file was not efficient enough to handle 
the growth of the ARPANET, and it needed to be replaced by a new network 
structure and name-resolution mechanism. That structure is Domain Name 
System (DNS), and the name-resolution mechanism employed is the 
Domain Name System name server, which is used to navigate the Internet 
and locate computers attached to the Internet. 


| Aside from this introductory chapter, this book assumes the reader has some knowledge of TCP/IP and 
| DNS. The first paragraph was a brief look at the history of DNS. 


_| For more Internet history information, go to http: //www.isoc.org/internet/history/. 
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What’s New and Different About DNS in 
Windows 2000 


If your experience with the DNS service is what came with Windows NT 4.0, without any serv- 
ice packs applied, a lot has changed. The DNS service that comes with Windows 2000 provides 
several features that move the Windows 2000 DNS service to an enterprise-level solution. 


With Windows 2000, the primary name service is DNS, whereas with Windows NT 4.0, the 
primary service was the Windows Internet Name Service (WINS). For instance, when an NT 
4.0 Workstation computer is started in a Windows NT 4.0 domain that is using TCP/IP as the 
transport protocol and WINS as the name server, the client computer contacts the WINS 
server to locate a domain controller and begin the authentication process. In a similar 

_ Windows 2000 networking environment, a DNS name server would be contacted rather 

than a WINS server. 


The DNS service provided with Windows 2000 is RFC-compliant and interoperates with any 
other RFC-compliant implementations of DNS and any version of DNS that supports Service 
Location (SRV) resource records (as defined in RFC 2782). Support for Dynamic Update (as 
defined in RFC 2136) can be used to support a Windows 2000 network. Some of the features 
provided with the Windows 2000 DNS service are the following: 


E Dynamic Update. When DNS was first contrived, the administrator of the DNS name 
server added and removed resource records manually, and it was expected that this 
information wouldn’t change too often. With Dynamic Host Configuration Protocol 
(DHCP) being used to provide client computers IP addresses, the data stored in a name 
server can change constantly. Dynamic Update provides a way for the client computer 
to send updates to the name server directly. For instance, when a client computer is 
started, it first broadcasts for an IP address (which a DHCP server provides), and the 
client computer or the DHCP server can then register that computer’s hostname and 
leased IP address with a DNS server. 


E Secure Dynamic Update. The DNS service can be configured to allow only secure 
dynamic updates to occur. The algorithm used is defined in the Internet-Draft “GSS 
Algorithm for TSIG (GSS-TSIG),” which finds its roots in the “Generic Security Service 
Application Program Interface (GSS-API)” as specified in RFC 2078. With secure 
dynamic updates, the client has to negotiate a secure means of communication with the 
DNS service before the dynamic update can occur. The client and server pass security 
tokens in TKEY resource records, as defined in the Internet-Draft “Secret Key 
Establishment for DNS (TKEY RR),” and the update occurs using TSIG resource 
records, as defined in Internet-Draft “Secret Key Transaction Signatures for DNS 
(TSIG).” For instance, the client might attempt to perform a nonsecure dynamic update. 
The server refuses the update, and the negotiation takes place using TKEY resource 
records. After successful negotiation, the client sends the dynamic update to the server 
using a TSIG resource record. After a successful update, the server sends a reply to the 
client using a TSIG resource record. 


What’s New and Different About DNS in Windows 2000 T 


E Incremental Zone Transfer (IXFR) Support. Rather than transfer the entire zone 
database using the full zone transfer mechanism (AXFR), the Windows 2000 DNS serv- 
ice is able to perform requests for an incremental change. For instance, when a client 
computer adds its resource record to a zone file, a master server for that zone can notify 
the secondary servers there is a change. The secondary servers can send the serial num- 
ber in the SOA record for the zone changed to the master, and the master can send only 
the changes made to bring the secondary server up to date. With dynamic updates, the 
savings in bandwidth can be significant. 


E Unicode Character Support. The UTF-8 character encoding (as defined in RFC 2044) 
is a superset of ASCII and a translation of Unicode (UCS-2) character encoding. The 
Clarification to DNS specification (RFC 2181) states that any binary string can be used 
as a DNS label. Originally, the character set that was used for DNS names only included 
the a-z, 0-9, and minus sign (—) characters (as defined in RFCs 952 and 1123), whereas 
NetBIOS names (NT 4.0 computer names) supported a much larger character set. If you 
are upgrading a network from NT 4.0 to Windows 2000 and some of the NT 4.0 names 
are not valid DNS names (as defined in RFCs 952 and 1123), you can enable the UTF-8 
support on the DNS server to recognize the nonstandard names rather than renaming 
all the NT 4.0 computers. 


| This process can be problematic when the extended character set is used on a Windows 2000 DNS server that interoperates with 
_.| fame servers that do not provide Unicode support. 


E Active Directory Integrated. The capability to configure Active Directory—integrated 
zones allows for multiple-master primary name servers, which eliminates a single point 
of failure for primary name servers. For instance, if a zone is AD-integrated, several 
name servers can modify the zone file, and the zone update between name servers is 
completed as part of the Active Directory replication process. If any one DNS server 
fails, there are still primary servers available for that zone. 


@ General Enhancements. Several enhancements have been made to the client, the 
server, and the management tool. The client has a more robust domain locator service 
and the ability to cache successful name resolutions locally, as well as supporting 
Negative Caching (as defined in RFC 2308). The DNS management console is a snap-in 
for the Microsoft Management console (MMC), which is a multipurpose tool that can be 
used to perform any management tasks on a Windows 2000 computer. An Access Control 
List (ACL) is associated with the management console, so you can select the user 
accounts that can use the DNS management tool to perform various tasks. 


Each of these capabilities is explored further in the upcoming chapters. The remainder of this 
chapter provides a breakdown of the authoritative Internet groups, as well as a brief summary 
of the RFCs and Internet-Drafts mentioned previously. 
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Internet Entities 


For all the vendors and developers to develop equipment that can interoperate with one 
another, standards have to be developed and implemented that establish the ground rules 
used for communications. In the early 90s, the Internet Society (ISOC) started playing a key 
role is the development of Internet standards. As shown in Figure 1.1, there is a hierarchy of 
organizations below ISOC that are responsible for making sure that standards are developed 
and that those standards are well thought out. Figure 1.1 and Table 1.1 provide a breakdown 


of those organizations. 
ISOC 
Organization of professionals that comment on policies and practices. 


IETF 
Engineers and develops protocols and 
standards. 
IAB IESG 
Provides technical management to the 
Defines the Internet’s architecture IETF and moves RFCs through the 
and provides guidance to the IETF. 
standards process. 
IRTF 


Small research groups that 
collaborate on Internet protocol topics. 


IANA 
Manages unique parameters, such as IP addresses and domain names. 


Figure 1.1 Each group within the hierarchy of the Internet Society has responsibilities. 


Table 1.1 Internet Society Organizations 


Organization Role 

Internet Society (ISOC): Organization of Internet experts that comments on policies 

http: //www.isoc.org and practices and oversees a variety of other organizations 
and task forces that help set Internet standards and policies. 

Internet Engineering Task Engineers and develops the protocols and standards for the 

Force (IETF): Internet. 

http: //www.ietf.org 

Internet Architecture Board Is responsible for defining the Internet’s overall 

(IAB): http: //www.iab.org architecture, providing guidance and direction to the IETF, 


and serving as a technology advisory group for the ISOC. 


Request for Comments (RFC) 9 


Organization Role 
Internet Engineering Steering Provides technical management of IETF activities and the 
Group (IESG) Internet standards process. Responsible for the movement 


along the Internet “standards track,” including final approval 
of Internet Standards. 


Internet Research Task Force Composed of a number of focused, small research groups 

(IRTF): http: //ww.irtf.org that work on topics related to Internet protocols, applica- 
tions, architecture, and technology. These groups help pro- 
mote the development of research collaboration and 
teamwork in exploring research issues. 


Internet Assigned Numbers In charge of all unique parameters on the Internet, 
Authority (IANA): including domain names and IP addresses. 
http: //www.iana.org 


At the Web sites listed, there is abundant information available about these groups and their 
role in the continued development of the Internet, as well as several great Internet historical 
documents. The ISOC Web site, in particular, has several links to good historical documents. 


If you want to keep up with the new Internet-Drafts and proposed RFCs, you can join a mail- 
ing list at the IETF Web site. Be warned that you will receive several emails per day with new 
Internet-Drafts attached. These are great to read but can be relatively time-consuming. 


Request for Comments (RFC) 


RFCs can provide detailed information about standards (even retired standards), document 
things that have been tried, or offer general technology information and guides. All of these 
are intended to provide information to the Internet community. Every RFC starts as an 
Internet-Draft, and can, from there, become an RFC by following the logical path depicted 
in Figure 1.2. 


Anyone can write an RFC, and the details for writing one are explained in RFC 2223 and in 
an Internet-Draft guideline, which are both available at the IETF Web site. There are differ- 
ent categories and subseries that RFCs can fall into. These can be found on the first page of 
the RFC. An RFC can be in the following categories: 


E Standard Track (STD). This category specifies an Internet standards track protocol 
for the Internet community and is open to suggestions for improvement. 


W Historic. When a standard becomes obsolete because a newer standard is introduced, 
the old RFC is changed to the Historic status. In this way, you can still review old stan- 
dards, but there is a pointer to the new standard that has taken the old standard’s 
place. 
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Figure 1.2 RFC Processing Paths. 


E Best Current Practice (BCP). This category specifies an Internet Best Current 
Practice for the Internet community and is open to suggestions for improvement. 

@ Informational (FYD. This category is used to provide information to the Internet com- 
munity. It is intended to bring information to the Internet community in a timely man- 
ner, and it is not part of a research and development effort. Many times, this type of 
document helps better explain an existing technology. 


Æ Experimental. This category is used to define an experimental protocol for the Internet 
community. It does not specify an Internet standard, but suggestions for improvement 
are welcome. These are typically part of a development or research effort and are pub- 
lished to provide general information and an archive of the work performed. 


The subseries into which an RFC can fall include the following: 


@ FYI. For Your Information. 
@ BCP. Best Current Practices. 
=E STD. Standard. 


RFCs in the Standard Track (STD) category also have maturity levels. These levels are 
reached during the different stages of a standards evolution as part of the development, test- 


ing, and acceptance process. The IESG moves RFCs through these different stages. The stages 
are as follow: 


E Proposed Standard. This is the entry level for an RFC on the standards track. It is 
typically stable, well designed and understood, and, after review by the Internet commu- 
nity, well received. 
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E Draft Standard. To reach this stage, an RFC has to have at least two independent and 
interoperable implementations from different code bases developed. In other words, 
there have to be two different manifestations that can work together before a draft stan- 
dard is obtained. 


E Internet Standard. Also called a Standard rather than Internet Standard, this has a 
high degree of technical maturity and significant implementation and operational expe- 
rience and provides significant benefit to the Internet community. 


With an understanding of who helps define and regulate Internet standards, how those stan- 
dards come about, and where to research those standards, you can now understand where to 
go for more information on the standards used to design and control the Windows 2000 DNS 
service because it is an RFC-compliant implementation of DNS. 


The Windows 2000 DNS RFCs 


The standards that originally defined DNS were RFC 882 and RFC 883, which were made 
obsolete by RFC 1034 and RFC 1035. RFC 1034 was made obsolete by yet another RFC or two, 
and so on. To understand what RFCs are applicable to most DNS servers and specifically to a 
Windows 2000 DNS server, you must be aware of the past and present RFCs that define that 
service. 


References are made obsolete as well because older documentation references older RFCs and 
it is important to understand what those RFCs cover, and what changes have been incorpo- 
rated in the newer RFCs. Following is a list of the RFCs that are pertinent to DNS, with a 
brief description of each, whether it is obsolete, and what RFCs took its place: 


HM RFC 882 (Domain Names - Concepts and Facilities). Made obsolete by RFC 1034, 
this RFC, along with RFC 883, introduces domain names and how they are used for 
ARPA Internet mail and host address support. It also defines the protocols and servers 
used to support and implement domain name facilities. The information in this RFC 
describes the conceptual framework of the domain system and some uses, but it is not 
a comprehensive document; it does not detail many uses, fields, and implementation 
details that are included in RFC 883. An understanding of RFC 882 is expected in order 
to understand RFC 883. 


E REC 883 (Domain Names - Implementation and Specification). Made obsolete by 
RFC 1035, this RFC expands on the concepts and topics introduced in RFC 882, and 
details an implementation of domain name servers and resolvers. It also specifies the 
format of transactions and the use of domain names with existing mail systems and 
other network software. The algorithms and internal data structures used are not 
requirements, but suggestions. As long as the external behavior is correct, the imple- 
menter is free to design his own internal structures. 
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@ RFC 1034 (Domain Names - Concepts and Facilities). Makes obsolete RFC 882, 
883, and 973 and is made obsolete by RFC 1065 and 2308. It is updated by RFC 1101, 
1183, 1348, 1876, 1982, 2065, 2181, 2308, and 2535. This RFC provides an introduction 
to the Domain Name System (DNS) and is a companion of RFC 1035. The domain sys- 
tem is a mixture of functions and data types that are an official protocol and functions 
and data types that are still experimental. This document provides detailed information 
on the official protocol, including standard queries, their responses, and most of the 
Internet class data formats. Experimental and obsolete features are also listed, but are 
clearly labeled. This RFC and RFC 1035 provide the background information necessary 
to understand DNS; therefore, RFC 1034 and 1035 should be read in their entirety. 


mM RFC 1035 (Domain Names - Implementation and Specification). Makes obsolete 
RFC 882, 883, and 973. It is updated by RFC 1101, 1183, 1348, 1876, 1982, 1995, 1996, 
2065, 2136, 2137, 2181, 2308, and 2535. This RFC describes the details of the domain 
system and protocol and is the companion document to RFC 1034. Because the domain 
system is intentionally extensible, new data types and experimental behavior should 
always be expected in parts of the system that operate outside of the official protocol. 
The official protocol parts include standard queries, responses, and the Internet class 
resource record data formats (for instance, host addresses). Changed from RFC 882 and 
883 are several definitions, so some previous definitions are obsolete. 


@ REC 1065 (Structure and Identification of Management Information for 
TCP/IP-Based Internets). Makes obsolete RFC 1034 and is made obsolete by RFC 
1155. This RFC provides the common definitions for the identification and structure 
of management information for TCP/IP networks, including a description of an object 
model for network management, as well as a set of types that describe management 
information. 


© RFC 1101 (DNS Encoding of Network Names and Other Types). Updates RFC 
1034 and 10385. This RFC details a specific method for entering and retrieving resource 
records that map network names and numbers. It provides ideas for a general method 
describing mappings between arbitrary identifiers and numbers. The method for map- 
ping between network names and addresses is a proposed standard, but the ideas for a 
general method are experimental. 


E RFC 1122 (Requirements for Internet Hosts - Communications Layers). Updates 
RFC 822 and is updated by RFC 2181. This RFC details requirements for Internet host 
software link layer, IP layer, and transport layers. Its companion RFC (RFC 1123) covers 
the application and support protocols. 

E RFC 1123 (Requirements for Internet Hosts - Application and Support). Updates 
RFC 822 and is updated by RFC 2181. This RFC defines and discusses the requirements 
for Internet host software, covering the application and support protocols. 

E RFC 1183 (New DNS RR Definitions). Updates RFC 1034 and 1035. This RFC 


defines five new DNS types for experimental purposes. The resource record designators 
are AFSDB, RP, X25, ISDN, and RT for these experimental types. 
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RFC 1348 (DNS NSAP RRs). Made obsolete by RFC 1637. Updates RFC 1034 and 
1035 and was updated by RFC 1637. This RFC defines two new resource records. These 
resource record designators are NSAP and NSAP-PTR and are meant to provide support 
for longer Internet addresses. 


RFC 1876 (A Means for Expressing Location Information in the Domain Name 
System). Updates RFC 1034 and 1035. This RFC defines a new experimental resource 
record type. The resource record designator is LOC. 


RFC 1982 (Serial Number Arithmetic). Updates RFC 1034 and 1035. This RFC 
defines serial number arithmetic as used in the Domain Name System. 


RFC 1995 (Incremental Zone Transfer in DNS). Updates RFC 1035. This RFC 
details the Incremental zone transfer (IXFR). When combined with NOTIFY, it provides 
a solution to slow propagation of zone updates. This is a relatively new DNS function, 


and it is important to understand NOTIFY and incremental zone transfers; therefore, 
RFC 1995 and RFC 1996 should be read in their entirety. 


RFC 1996 (A Mechanism for Prompt Notification of Zone Changes). Updates 
RFC 1035. This RFC details DNS NOTIFY, which is used to actively send zone update 
announcements to secondary name servers whenever zone information changes. 


RFC 2065 (Domain Name System Security Extensions). Made obsolete by RFC 
2535. Updates RFC 1034 and 1035. This RFC details the security extensions available 
for resolvers and applications through the use of cryptographical digital signatures—in 
other words, key distribution services. Several types of resource records are defined in 
this RFC, including the TKEY and TSIG resource records covered in Chapter 12, 
“Securing and Troubleshooting DNS Communications.” This RFC covers advanced topics 
that are used to secure your DNS service, but is best read after you have a firm under- 
standing of operational DNS. 


RFC 2136 (Dynamic Updates in the Domain Name System (DNS Update)). 
Updates RFC 1035. This RFC details dynamic update operations in DNS. If a given set 
of prerequisites is satisfied, updates to a zone can be made internally, rather than exter- 
nally, by editing a zone’s master file. This is how client computers can automatically 
update a DNS zone file. For instance, when a client computer is started and obtains an 
IP address, it can be configured to send a resource record update to the DNS name 
server it is configured to use. This is an important RFC to read in its entirety. 


RFC 2181 (Clarifications to the DNS Specification). Updates RFC 1034, 1035, and 
1123. Is updated by RFC 2535. This RFC identifies eight areas that can be considered 
problematic and addresses each separately. These include IP packet headers from multi- 
homed computers, TTL records in certain circumstances, correct handling of zone cuts 
(delegations), issues with SOA records, a precise definition of TTL, use of the TC header 
bit, the issue of what a canonical name is, and what a valid DNS label is. Of note on this 
last subject is the notion that any binary string can be represented as a valid label. An 
example of this is the underscore, which is, by the definition presented in RFC 2181, a 
valid character for a DNS label. 
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E RFC 2535 (Domain Name Security Extensions). Makes obsolete RFC 2065. Updates 
RFC 1034, 1035, and 2181. This RFC standardizes extensions of the DNS protocol to 
support DNS security and public key distribution. This RFC incorporates the feedback 
from RFC 2065 to provide information on key distribution and authentication, and pro- 
vides full DNS security. A “lightweight” alternative of this is detailed in an Internet- 
Draft GSS-TSIG. 


Æ RFC 2782 (A DNS RR for Specifying the Location of Services (DNS SRV)). 
Updates RFC 1035, 1183, and 2052. This RFC defines and details SRV resource records. 
These records are used as locator resource records. They help define various network 
services available on a given network. They can be used to help perform load balancing 
by providing fields for setting priority and weight to a DNS entry. This is crucial to 
understanding networking in Windows 2000 and is a must-read for anyone configuring a 
network with DNS or configuring a Windows 2000 network. 


“| RFC 2782 defines SRV resource records and should be read in its entirety. 


It is clear from the large number of RFCs listed that there are a number of documents that 
cover DNS. Some RFCs should be read in their entirety before continuing with this book and 
certainly before implementing DNS for your corporate network. As a general rule, it is worth- 
while to read all the RFCs that define today’s DNS. 


IETF Drafts 


There are several Internet-Drafts that further define the DNS service provided with the 
Windows 2000 Server products. These drafts are not yet of RFC stature, but they do further 
expand on the DNS service. Internet-Drafts can be found at the IETF Web site listed in 
Table 1.1. Searching for these can be difficult because the number on the draft does change 
from time to time. 


In the following drafts, the actual number of the current document is replaced with an aster- 
isk. When searching for these documents, the asterisk is a placeholder for the number of the 
current draft. 


You can join a mailing list (available at the IETF Web site) to receive Internet-Drafts as they 
are submitted. The Internet-Drafts pertinent to Windows 2000 DNS are the following: 


HZ Interaction between DHCP and DNS (draft-ietf-dhe-dhcp-dns-*.txt). This draft 
details how DHCP clients and servers should use the Dynamic DNS Updates mecha- 
nism (as defined in RFC 2136) to update the DNS name-to-address and address-to-name 
mappings contained in resource records. This is necessary to keep the information con- 
tained in the DNS zone current because the client’s IP address can change because it is 
only leased from a DHCP server. 


BIND Capabilities and Compatibilities 15 


M Secret Key Establishment for DNS (TKEY RR) (draft-ietf-dnsind-tkey-*.txt). 
This draft describes a TKEY resource record that can be used in several different modes 
to establish shared secret keys between a DNS resolver and server—that is, to exchange 
keys between a resolver and server. 


E Secret Key Transaction Signatures for DNS (TSIG) (draft-ietf-dnsind-tsig-*.txt). 
This draft defines a means to more efficiently authenticate and secure DNS messages 
using shared secret keys and one-way hashing. It can be used to authenticate approved 
clients or responses coming from an approved name server. This draft does not, however, 
provide a mechanism for setting up such keys other than by manual exchange of those 
keys. 

E GSS Algorithm for TSIG (GSS-TSIG) (draft-skwan-gss-tsig-*.txt). This protocol 
specifies an algorithm based on the Generic Security Service Application Program 
Interface (GSS-API) defined in RFC 2078. The security services that can be offered 
include authentication, integrity, and confidentiality, and they are not protocol- or 
mechanism-dependent. 


M@ Using the UTF-8 Character Set in the Domain Name System (draft-skwan-utf8- 
dns-*.txt). This document expands the allowable character set that can used in DNS 
labels to include the UTF-8 character encoding (as defined in RFC 2044) and still be 
able to interoperate with non—UTF-8-aware DNS implementations. 


By understanding the RFCs and Internet-Drafts that define the DNS service provided with 
Windows 2000, you will be able to better understand how this service works. It is important to 
read through each of the RFCs and Internet-Drafts listed to have a complete understanding of 
DNS specifications. 


BIND Capabilities and Compatibilities 


Any DNS service that is RFC-compliant and supports dynamic updates and SRV resource 
records is compatible with Windows 2000 Active Directory and can interoperate with the 
Windows 2000 DNS service. The first Berkeley Internet Name Domain (BIND) implementa- 
tion to work well in an Active Directory networking environment is BIND 8.1.2. 


Configuring BIND and Windows 2000 DNS on the same network is discussed in detail in later 
chapters. The Windows 2000 DNS service exchanges zone data and interoperates well with 
any RFC-compliant DNS implementation, but not all DNS implementations can support 
Windows 2000 Active Directory. In other words, standard DNS interactions work well with any 
DNS implementation and Windows 2000 DNS, but if Active Directory is implemented, you 
must design the DNS structure with this in mind. 


THE NAME RESOLUTION 
PROCESS 


DNS was first designed and used to resolve a hostname to an IP address. 
For instance, a computer named ClientA needs access to a file on a com- 
puter named FileServerB. To communicate with FileServerB, ClientA must 
resolve the computer name of FileServerB to its IP address to establish 
communications. 


ClientA could query a DNS name server for name to IP address resolution 
of FileServerB. The DNS name server would either be able to provide the IP 
address requested, or communicate with another name server that might 
have the IP address to the computer named FileServerB. This is the name 
resolution process in a nutshell. 


In a Windows 2000 network, the DNS service is the primary name resolu- 
tion mechanism used to locate networked computers. The DNS Service is 
also the network service locator, which is used to locate computers that are 
providing network services, such as a computer that can authenticate a user 
logon attempt. In Windows NT 4.0 networking, this task is performed by 
the WINS service, which provides NetBIOS name resolution and service 
location services for a Windows NT-based network. 
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The Physical and Logical Internet 


The Internet is the physical network that connects computers all across the world. Each com- 
puter is assigned an IP address, which is used by the IP transport protocol to pass data pack- 
ets from one computer to another across the Internet. The Domain Name System (DNS) is the 
logical structure that provides a user-friendly navigation and naming mechanism for use on 
the Internet. DNS consists of three major components: the domain name space, the name 
server, and the resolver. The three components that make up DNS can be considered the logi- 
cal network structure, the server, and the client. 


The physical aspect of the Internet is the hardware used to connect computers on the 
Internet and the transport protocol that allows the computers to communicate with one 
another. Figure 2.1 shows some of the components that make up the Internet. 


Network 1 Network 2 Network 3 Network 4 


Router 2 S Router 3 
= 10.2.1.1 = 


Router 1 


10.1.1.1 


W 
e 


nr p oe La | 


Network 5 Network 6 


1E maa C5 


10.0.0.1 


Figure 2.1 The physical aspect of the Internet includes the hardware used to create and con- 
nect networks around the world, and the transport protocol used to route packets 
across different networks from the source computer to the destination computer. 


Some of the components that the Internet is comprised of include large backbone networks 
that connect major cities and countries, smaller networks that connect client computers to 
Internet service providers (ISPs), routers that can route packets between various local area 
networks (LANs), wide area networks (WANs), and the IP transport protocol, which provides 
the packet structure used to route packets from one physical network to another, until finally, 
the packets end up at the desired destination. 


The logical aspect of the Internet is the domain name system (DNS), which is used to create a 
hierarchical order for the computers on the Internet, then to associate those computers with 
their IP addresses in much the same way that a person is given a human-friendly name which 
can be associated with a phone number or government-assigned number such as a Social 
Security number. Figure 2.2 depicts the logical structure of the Internet. 
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Figure 2.2 The logical aspect of the Internet is comprised of user-friendly names and their 
associated IP addresses configured in a hierarchical structure. 


To locate and communicate with a person in another part of the world over the Internet, you 
must use a fully qualified name to identify the person, and then resolve the person’s name to 
a number you can use to contact that person. For example, to contact Joe, you would identify 
Joe in a relative structure, such as Joe in the house at the corner, in CityX, in CountryY, and 
then associate Joe with a phone number, or other unique number that could be used to com- 
municate with Joe. If you lived next door to Joe, you could simply say Joe, or Joe next door, 
and not use a fully qualified name to indicate Joe. 


With DNS, the same type structure is used. Each computer has a hostname, and then the fully 
qualified domain name places that unique hostname in a specific location in the domain name 
space. For instance, Serverl is a computer connected to domain 501redtab, which is located in 
the COM domain under the root of the Internet. 


The DNS Architecture 


The Domain Name System (DNS) is a hierarchical, distributed database that provides a logical 
structure for the Internet. DNS is hierarchical because there is a single root with several 
defined nodes below it, and below each of the defined points, are more defined points. To locate 
a point, you reference it according to the path down the tree structure you would take to reach 
the desired point. 


DNS is a distributed database because there is not a single computer with a database that 
contains all the information about each computer connected to the Internet. Rather, the infor- 
mation is stored on many computers, and a referral system is used to locate the computer that 
has the information you need. If one name server cannot provide the IP address for a specific 
computer on the Internet, the name server can provide the IP address of a name server that 
might have more information for the computer being located. 
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Domain Name Space 


The domain name space is the hierarchical (or tree) structure created by the logical ordering of 
computer names on the Internet, and is structured in the same manner as the files and folders 
on a hard disk partition. Like a hard disk partition, the domain name space has a single root 
at the top of the structure, with branches below it. Each point along the tree structure is 
known as a node. Adomain is any named node in the domain name space, and a domain name 
defines that point in the tree structure. Figure 2.3 shows the DNS structure with the top-level 
domains, second-level domains, and subdomains below that. 
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Figure 2.3 This is the DNS hierarchical structure with the root-level domain, top-level 
domains, and subdomain, as well as a name server and resolver. 


At the top of the hierarchical (or tree) structure is the root domain, represented by a period “.”, 
which also is referred to as a dot. Below the root domain are top-level domains, and then sub- 
sequent subdomains. 
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Top-Level Domains 


There is a fixed number of top-level domains, which separate the Internet into logical groups. 
The IANA Web site (http://www. iana.org) has information on the top-level domains, and RFC 

1591 (http: //ww.ietf.org/rfc/rfc1591.txt) is an informational RFC on the top-level domains. 
The top-level domains are 


E COM—Probably the most well-known top-level domain, the COM domain is intended for 
commercial entities, that is, companies. 


mM EDU—The EDU domain is the education domain, and was originally intended for all 
educational institutions. Recently, this domain has been limited to universities and four- 
year colleges. 


W NET—This domain is meant only for computers of network providers, such as adminis- 
trative computers and network node computers for a network. Any customer computers 
of a network listed under NET are meant to register their own domain, not register as a 
node of a second-level domain under NET. 


wW ORG—This domain is the meant for nongovernment organizations that don’t fall under 
any of the other top-level domains. For instance, if you formed an organization for bad 
chess players, you could register a second-level domain under the ORG domain to pro- 
vide a Web presence for all bad chess players. 


m@ INT—The INT domain is for organizations established by international treaties or inter- 
national databases. 


mM GOV—At first, this domain was for any government office or agency, but recently, has 
been restricted to agencies of the U.S. Federal government only. Any state or local agen- 
cies are registered under their respective two-letter state code. 


© MIL—As stated earlier, this top-level domain is used by the U.S. Military. 


Mm XX—This domain is used for countries, with each country having a two-letter country 
code. For instance, the country code for the United States is US, and for the United 
Kingdom is UK. Most of the top-level country codes are defined in ISO standard 3166 
(http: //www.iso.ch), and several generic second-level domains for the US domain are 
defined in RFC 1480 (http: //ww.ietf.org/rfc/rfc1480. txt). 


_ Adding More Domains 
_ If more top-level domains were added, they would be defined by IANA and an RFC would be generated detailing the new domains 
i and their use. 


Domain Names and FQDNs 


Below the top-level domains are second-level domains, and below that, there exist even more 
subdomains. When describing a domain in the domain name space, you refer to it by its fully 
qualified domain name (FQDN). A fully qualified domain name describes a domain from the 
nearest node to the top of the domain name space, and uses periods to separate the domains 
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crossed to reach the root. For instance, a domain named recruiting found under the 501redtab 
domain, which is found under the com domain, which is under the root domain, would have an 
FQDN of recruiting.501redtab.com. The period that represents the root domain is understood, 
and is generally not included in the FQDN, but is included when configuring a DNS name 
server. Figure 2.4 shows recruiting.501redtab.com and its relative location in the domain 
name space. 
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Figure 2.4 The FQDN recruiting.501redtab.com. is shown in the domain name space. 


A domain name can include up to 63 characters, and the total length of an FQDN can be as 
many as 255 characters. Only certain characters can be used in a domain name, and each 
name in a domain must be unique, just as each file stored in a folder must be unique. That is 
to say, each FQDN on the Internet must be unique, but not each domain name. For instance, 
the FQDN ww.501redtab.com would be different from a site ww.501redtab.net. Although each of 
these has a domain name of 501redtab, the FQDNs are unique, and the Web sites associated 
with each are extremely different. 


RFC 952 (http: //ww.ietf.org/rfc/rfc0952.txt) describes the basic characters that are allowed 
in domain names. RFC 1123 (http: //ww.ietf.org/rfc/rfc1123.txt) defines what the allowable 
first character of a domain can be, as well as the length of a domain name. RFC 2181 
(http://www. ietf.org/rfc/rfc2181.txt), clarifies several items, including the following: 


E A domain name can contain up to 63 octets (characters) and the full name (FQDN) can 
contain up to 255 octets. 


@ Any binary string is allowed as a label in a resource record. The only limitation is that 
the label be no longer than 63 octets in each label, with a total of 255 octets allowed. 
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Name Server 


A DNS name server is the server component of the Internet that helps client computers resolve 
domain names or computer names to IP addresses, or IP addresses to computer names or 
domains. A name server has two main tasks: 


M@ To respond to name resolution requests made by client computers. 


E To respond to name resolution requests made by other DNS name servers on the 
Internet. 


Currently, there are more than four billion IP addresses in use on the Internet, and the num- 
ber of FQDNs associated with those addresses is even greater. When IPV6 is fully imple- 
mented, the number of IP addresses will be even greater. No single name server can hold all 
the locating information for all the IP addresses and domains that comprise the Internet; 
therefore, a name server stores only a portion of that information. 


_ The IPV6 protocol is the replacement for the currently used version of IP which is IPV4. IPV4 is based on a 32-bit hexadecimal 

: _ address. IPV6 is based on a 128-bit hexadecimal IP address. For more information on the IPV6 protocol, refer to RFC 1752 to 

! -see the recommendations for the new protocol, RFC 1883 for the protocol’s specifications, and RFC 1884 for the protocol’s archi- 
= tectural description. 


The information is stored in a database, which also is referred to as a zone. A zone is a data- 
base, stored on a DNS name server, that contains information about domains located in a con- 
tiguous portion of the domain name space. A zone is used to answer query requests by client 
computers and other name servers. As a computer is added to a network, it is configured with 
a host (or computer) name, an IP address, and the IP address of the name server that it will 
use for DNS name resolution. On the DNS server, the name assigned to the computer, along 
with its IP address, is added as a record to the database on the name server. 


When the host computer’s IP address is added to the name server’s zone database, the name 
server is authoritative for the host that is added, as shown in Figure 2.5. A name server is 
authoritative if it has information that can be used for name resolution of a domain or host, 
which is not to say the name server has any control over the domain or host. This is similar to 
a receptionist at a business. The receptionist is an authority over the tenants in the building, 
because the receptionist can help locate the tenant, not because the receptionist controls the 
tenant. 


Each zone contains information about a portion of the domain name space. Each entry in the 
zone database is called a resource record (RR). A resource record is an entry into a DNS zone 
database file that provides information about a computer (which is also known as a host), net- 
work service, or domain in a zone. 


`: There are several types of resource records stored in a zone database file, several of which are described in RFC 1035 and RFC 
= 2782. 
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Figure 2.5 A zone is a portion of the domain name space that at least one name server is 
authoritative for. 


When a client resolver or name server sends a query to a name server, and the name server 
provides an answer, the information is valid only for a certain amount of time. The amount of 
time the information is good for is set by the name server providing the name resolution infor- 
mation, and is known as the time to live (TTL) for the response. 


A time to live (TTL) is a number added to a resource record that represents the amount of time 
(in seconds) that the name resolution information sent by a name server can be used by the 
client resolver or name server performing the query. 


The name server that hosts a resource record assigns the resource record a time to live (TTL) 
time. The time is measured in seconds, and when a name server query is performed, the TTL 
is included with the response. When the TTL expires, the computer storing the resolution 
information in cache must flush the information. In this manner, resolution information is 
kept current. Figure 2.6 shows the TTL for a resource record being resolved. 


1. ClientA queries NServer1 for the IP address of WebServer3. 
2. Nserverl queries Nserver2 for the IP address of WebServer3. 


3. Nserver2 provides the IP address for WebServer3, along with the time to live (TTL) for 
the resolution information. 


4, Nserverl caches the information (including the TTL) and send the information to 
ClientA, who also caches the information. 


5. When the TTL expires for the resolution information stored in cache, ClientA and 
Nserver1l flush the resolution information from cache. 
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Figure 2.6 TTL information sent with name resolution information determines how long the 
information can be stored in cache. 


The size and shape of a zone are based on the resource records it contains. Because DNS is a 
distributed database, name servers store only information that provides name resolution over 
a portion of the domain name space. Therefore, a zone typically has resource records for sev- 
eral domains and hosts. However, all resource records must be part of the same contiguous 
name space. Figure 2.7 shows some examples of proper and improper zones). 


“” Root 
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Zone 


Figure 2.7 Some examples of proper and improper zones. 
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Name servers that have authority over zones located higher in the domain name space must 
have resource records for name servers that are authoritative over zones that are below it in 
the domain name space. In this way, when a query is received by a name server higher in the 
domain tree, the name server can provide the IP address of a name server lower in the domain 
tree. 


With the Windows 2000 DNS service, the database can either be populated with resource 
records manually, by an administrator entering the information, or automatically, by a com- 
puter that is booting. As part of the startup process, the computer can send information to the 
DNS name server requesting its name and IP address be added to the database. 


Resolver 


The client computer (the computer that is requesting information from a DNS name server) 
has a piece of software installed that is known as a resolver. A resolver is a program on a client 
computer that enables it to form queries for name resolution by a DNS name server. A resolver 
is sometimes referred to as a resolver stub, because it is a small portion of a larger piece of 
software, such as the TCP/IP stack. 


Computers running Windows 2000 have the capability to query a name server, but also can 
register their resource records with a DNS name server that supports dynamic updates, as 
specified in RFC 21386 (http://www. ietf.org/rfc/rfc2136.txt). 


Recursive Query 


If you configure a DNS client or server for recursion, you are configuring that client or server 
to form and answer queries for an absolute answer. That is, provide the IP address requested, 
or reply that it does not exist. A recursive query (as shown in Figure 2.8) is typically a request- 
the-resolver stub on a client computer form, which requests the IP address associated with a 
given computer name or domain name in the domain name space. The response that can be 
provided to this type of query is absolute, so the name server that receives a recursive query 
either provides the resolver with the IP address requested, or sends a failed-resolution mes- 
sage, such as an unknown host message, back to the client. 


The name server handling the resolver request can contact and query other name servers for 
name resolution, but the response to the resolver is either: 


M Yes, here is the IP address you requested. 


or 


E No, an IP address for the host you requested could not be found. 
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Figure 2.8 A client computer’s resolver stub performing a recursive query. 


RFC 1034 and RFC 1035 (http: //ww.ietf.org/rfc/rfc1034.txt and 
http://www. ietf.org/rfc/rfc1035.org), respectively, provide information about recursive 
queries. 


Client computers are typically configured to perform recursive queries, whereas DNS name 
servers are typically configured to use iterative queries, which are discussed in the next sec- 
tion. When configured for recursive queries, the client computer is putting the burden of per- 
forming the DNS name resolution on the name server. Typically, servers are more powerful 
computers than client computers; therefore, the server is better able to perform the query than 
the client. Also, the server might have a faster connection to the Internet, or might be config- 
ured with access outside of a firewall, where a client might not be able to gain access. 


Iterative Query 


If you configure a DNS client or server for iteration, you are configuring that client or server 
to form and answer queries with the best answer available locally. An iterative query is a 
request, typically performed by a DNS name server, that requests the IP address (or best 
answer available) associated with a given computer name or domain name in the domain 
name space. If the name server being queried is not authoritative for the FQDN being 
resolved, but has information about a name server located lower in the domain name space in 
the FQDN, a response is sent back with the best answer the name server can provide, which is 
the IP address for the name server nearer the FQDN in the domain name space. 


Because name servers are required to register with at least two parent name servers (name 
servers located higher in the domain name space), parent name servers should always be able 
to provide the IP address for a name server that is nearer the FQDN being resolved. In this 
manner, name servers located nearer the top of the domain name space have information 
about name servers that are lower in the domain name space. Figure 2.9 shows an iterative 
query for a domain. 
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Figure 2.9 A DNS name server performs an iterative query when a client computer requests 


name resolution and the name server does not have resolution information 
stored locally. 


An iterative query is initiated when a client computer sends a recursive query to its DNS 
name server. The steps performed in an iterative query of the domain name space are 


1. 


2. 


The computer ClientA sends a recursive query to the name server it is configured to use. 
In this example, NS1. 


NS1 attempts to provide resolution to the ClientA’s recursive query by checking its local | 
cache or parsing a zone file it hosts. 


If the NS1 cannot satisfy ClientA’s request with locally stored information, it locates the 
cache.dns file it stores locally, which contains a list of the root-level DNS name servers 
on the Internet. 


NS1 then contacts a root-level name server (NS2) using an iterative query. The query 
is a request for name resolution to the FQDN, or a reference to a name server located 
closer to the FQDN being resolved. 


NS2 sends the best answer to the request it has stored locally back to NS1, which in 
this example is NS3, a name server located down the .com portion of the domain name 
space. 


NS1 contacts NS3 using an iterative query. Again, the query is a request for FQDN or 
a name server located closer to the FQDN that might have better information for the 
FQDN. 
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7. NS3 sends the best answer to the request it has stored locally back to NS1, which in 
this example is NS4. This process continues until a name server is located that is 
authoritative (can provide name to IP address resolution) for the FQDN being 
requested. In this example, NS4 hosts the zone that the FQDN is a part of and sends 
the requested IP address back to NS1. 


8. NS1 responds to the recursive query the resolver on the client created with the IP 
address requested. 


During the name resolution process, several things other than locating an IP address and pro- 
viding resolution to the client query can occur. Two of the most common are 


E The name being queried for could not be found, in which case the client will receive a 
message back to that effect. 


W The amount of time the information received from the iterative query is valid for 


expires, in which case the client will receive a response back that the destination is 
unreachable. 


Caching Resolutions 


To speed up the name resolution process, one of the functions of a resolver and a name server 
is to cache name resolutions that have already been performed locally. That way, if another 
resolver requests a previously accessed name resolution, the name server might have current 
information stored locally that can be used to speed up the name resolution process. 


To keep resolution information current, the information in cache can stay for only a set 
amount of time, and then the name server or resolver must flush the resolution information 
from its cache. The amount of time the resolution can be stored in cache is set by the name 
server providing the resolution as part of the resource record. When a resource record is cre- 
ated on a name server, a TTL value is set as part of that record. 


Server Caching | 


With Windows 2000, the DNS service has server-side caching. This allows the server to store 
resolution information for a fixed amount of time, and to use that information for future reso- 
lution requests. The information is stored in memory, so the longer the name server is up, the 
more resolutions the name server can resolve with locally stored information, but the more 
memory used storing that information. 


When a computer running Windows 2000 server is started, and the DNS service is configured, 
the DNS service uses approximately 4MB of memory. Each of the zones the name server hosts 
is loaded into memory, and, as the name server performs resolutions, the resource records 
resolved are stored in memory. Each resource record uses approximately 100 bytes of memory. 
As might be guessed, the amount of memory used to support DNS can be extensive if the 
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name server hosts one or more large zones, or if the name server is very active resolving 
queries for resources it is not authoritative for. 


Client Caching 


The Windows 2000 client resolver also has the capability to cache name resolutions. This 
allows the client computer to use locally stored name resolution information rather than hav- 
ing to query a DNS name server to identify the IP address for a remote computer. This feature 
is not necessary for the client to be able to communicate with a DNS name server, but does 
provide better performance in the name resolution process. 


Successful Caching 


The client caching component runs under the services.exe context, and is named dnscache. 
This service provides a number of capabilities, including 


E Storing successful queries. 


E Removing previously cached entries, if they no longer appear to be valid because they no 
longer respond. 


E Managing which of the configured name servers to use based on a failure to communi- 
cate to name servers. 


E Tracking PnP network adapters, and the domain name assigned to each. 


HM Requesting multiple “A” resource records be prioritized based on the network the client 
is on, rather than the order provided by the DNS name server configured to use the 
round-robin method. 


M Accepting a response from nonqueried IP address. 
@ Automatically reloading the Hosts file into cache when the Hosts file is modified. 
© Ceasing to perform queries if all the resolver’s queries time out with no response. 


| An “A” type resource record is a record that lists a computer's hostname and its associated IP address. 


A number of these capabilities can be enabled and disabled through the Registry. The DNSCACHE 
settings are stored in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache. 


Unsuccessful Caching 


The client resolver also has the capability to store negative resolution entries. For example, if 
the client resolver attempts to resolve ww.501redtab.con instead of ww.5@1redtab.com, the name 
cannot be resolved, so the resolver will cache the information for a specified amount of time. If 
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another attempt is made to resolve that name, the resolver will refer to its local cache to 
return a destination unreachable message without contacting a DNS name server. 


You can modify the TTL for unsuccessful entries, or disable the capability of the resolver to 
cache unsuccessful entries. These settings can be modified under the same Registry key as the 
other DNS client settings. 


WINDOWS 2000 DNS 
CLIENTS AND SERVERS 


This chapter will provide an overview of the different ways you can config- 
ure the DNS service in Windows 2000 and the impact that has on the 
installation. The first portion of the chapter defines the different types of 
zones that can be created and how to configure a DNS name server to sup- 
port those zones. The second portion of the chapter will cover installing and 
configuring the DNS service and provides information on various DNS 
clients and what capabilities of the Windows 2000 DNS service they 

can use. 


Zone Types 


The two main categories of zone you can create with the Windows 2000 
DNS service are standard zones and Active Directory Integrated zones. A 
standard zone is created as a text file stored in the DNS directory on the 
name server’s hard disk. An Active Directory Integrated zone is stored as 
part of the Windows 2000 Active Directory and does not have a text file 
associated with it. 


Standard Zones 


With DNS name servers that host standard zones, one name server is con- 
figured to maintain a read/write copy of the zone database. All changes to 
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that zone are made on the name server hosting the primary zone database file and, as changes 
are made to the database on that name server, it sends the database updates to other name 
servers. In this manner, there are several name servers that can respond to queries from 
client resolvers and other name servers, which balances the workload among several servers 
and provides some fault-tolerance if one of the name servers is not functioning properly. 


The following are the types of standard zones that can be created: 


E Standard Primary—A standard primary zone is the read/write copy of the zone data- 
base. Changes made to the zone database must be made on the name server that con- 
tains the primary zone database. 


M Standard Secondary—A standard secondary zone is the read-only copy of the zone data- 
base. Changes made to the zone database are made on the name server that hosts the 
primary zone database file and then, using an update process, a name server hosting a 
secondary copy of the zone receives updates. _ 


Æ in-addr.arpa—An in-addr.arpa zone is used for reverse lookup and would be used to sup- 
port reverse lookup queries. That is, an IP address is provided and resolved to a name. 
The information in these zones is typically used by network applications for verification 
rather than identification or as a tool for monitoring and troubleshooting the DNS 
service. 


Active Directory Integrated Zone 


Active Directory Integrated zones get their name from the Windows 2000 Active Directory. 
The reason for this is an Active Directory Integrated zone is created using the DNS tool, but it 
is stored in the Active Directory instead of as a file on the name server’s hard disk. Because an 
Active Directory Integrated zone is part of the Active Directory, the name server hosting this 
type of zone must also be a Windows 2000 domain controller. 


| Active Directory is directory service provided with Windows 2000 networking. The information in Active Directory defines what net- 
| work objects can be created and what attributes each object can have. Active Directory provides a hierarchical structure employed 
-by users and administrators to organize and locate resources, as well as manage a network and implement security. 


Windows 2000 Active Directory is based on a multiple master model, which means there is not 
one specific computer that maintains the Active Directory. Changes to the Active Directory can 
be made on any domain controller, and those changes are propagated to all the domain con- 
trollers for the domain. 


Because an Active Directory Integrated zone is stored in Active Directory, there is no primary 
or secondary zone hosted on a single name server. Rather, changes to an Active Directory 
Integrated zone can be made on any name server hosting the zone, and those changes will be 
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propagated to all the name servers through Active Directory replication. The following are the 
types of Active Directory Integrated zones that can be created: 


© Forward Lookup Zone— An Active Directory Integrated forward lookup zone serves the 
same purpose as a standard primary zone but is maintained differently. The zone data- 
base is not stored in a file on the name server; it is stored as part of the Active Directory 
information. Because any name server that hosts an Active Directory Integrated zone 
has a read/write copy of the zone and can make changes to the zone information, there 
is no primary or secondary zone. Replication is performed through the Active Directory 
replication process, which is performed through a secure, encrypted replication process. 


© Reverse Lookup Zone—A reverse lookup zone is used for reverse lookup and is similar to 
the standard in-addr.arpa zone. The reverse lookup zone is stored and updated in the 
same manner as the Active Directory Integrated forward lookup zone. 


__ For more in-depth coverage of Active Directory, see the Concise Guide to Windows 2000 Active Directory from Que 
=- (ISBN# 0-7897-2357-3). Available November, 2000. 


Name Server Types 


If a name server hosts a certain type of zone, the name server is typically referred to as that 
type of name server. For instance, if you configure a name server to host a primary zone 
named ZoneA, the name server would be called a primary name server for ZoneA. The types of 
name servers you can configure on a computer running the Windows 2000 DNS service are the 
same as the zone types previously listed, as well as two other types: 


E Master (for a standard zone)—Any name server that hosts a primary or secondary copy 
of a zone database and is also responsible for sending updated copies of the database to 
other name servers is known as a master name server. 


E Caching-only—A caching-only name server does not host any zone databases and does 


not respond to queries from other name servers, but it does perform name resolution for 
client resolvers. 


A DNS name server can be used to host several zones, so the name server can be a primary 
name server for one zone and a secondary name server for a different zone. If the name server 
hosts the primary name server for a zone, it is a master name server for that zone by default. 


Primary Name Server 


A name server that is a primary name server maintains a zone database file. Any changes 
made to the zone are made to the primary zone database file, and then replicated to any sec- 
ondary name servers for that zone. In addition to maintaining the information for the zone, 
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the primary name server also responds to queries from client computers on its network 
and other name servers on the Internet. Figure 3.1 shows a primary name server for 
501.redtab.com. 


ORG 


“a” INTERNET ROUTE 


INT 


PRIMARY 
ZONE FOR 
501REDTAB.COM 


501REDTAB 


Figure 3.1 Primary name server for the 501redtab.com domain. 


To create a new primary zone on a Windows 2000 DNS server, from the DNS tool (located in 
the Administrative Tools menu), you start the New Zone Wizard, select Standard Primary, and 
complete the wizard. By default, the wizard will create a file with the same name as the zone, 
place the file in the systemroot\system32\dns directory, and create SOA (Start of Authority) and 
NS (Name Server) resource records in the zone file. After any changes are made to the zone 
database file, a backup copy of the file is created in systemroot\system32\dns\backup. Along with 
the file being created in the folder, a key is added to the Registry 
HKLM\SYSTEM\CurrentControlSet \Services\DNS\zones\zonename for each zone created. 


L SOA, NS, and several other types of records are discussed in detail in Chapter 8, “Exploring Resource Records,’ page 153. 


After the Primary zone is created, you can configure and update the zone using the DNS tool 
located on the Administrative Tools menu. While using the DNS tool is the preferred method, 
you can also edit the zone files directly using a text editor. 


Secondary Name Server 


Before you can create a secondary zone database, the primary zone must already be created on 
another name server. To create a new secondary zone database file, start the New Zone Wizard 
in the DNS tool, select Standard Secondary, and complete the wizard. Once created, the zone 
will be populated with the records from the master name server from which you will receive 
the zone transfers. 


Name Server Types 37 


Figure 3.2 shows Server1 hosting the standard primary zone for the 501redtab.com zone with a 
secondary server named Server2 being configured as a secondary name server. 
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Figure 3.2 A primary server for the 501redtab zone named Serverl, which is also the master 
server for Server2. Server2 is the master server for Serversd. 


W Serverl is primary and master for server 2. 
WŒ Server2 is secondary with Serverl acting as master and updating Server2. 


M Server’ is secondary with server2 acting as master and updating server 3. 


Server2 is configured with Server1 as its master; therefore, Server2 receives its zone updates 
from Server1. Server3 is configured as a secondary name server for the 501redtab.com zone and 
is configured to use Server2 as its master. Therefore, Server3 receives its zone updates from 
Server2. 


Master Name Server 


A master name server provides zone updates to a secondary name server. Both standard pri- 
mary and standard secondary zones can be master name servers, and there is no additional 
configuring needed to make a name server a master name server. In Windows 2000, you must 
list all the name servers for a zone in the primary zone database using NS resource records. 
To do this using the DNS tool, do the following: 


1. From the Administrative Tools menu, click DNS. 
2. Right-click the primary zone you want to list the name servers for, and then click 
Properties. 


3. Under the Name Servers tab, add the name servers that will host the zone database file. 


The NS resource records will be created automatically when you add them to the name server 
list. After the name servers for the zone are listed on the name server tab, each time you cre- 
ate a secondary zone, you can provide the address of any of the name servers listed, thus mak- 
ing the server listed a master for the secondary you are creating. 
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Caching-Only 


A caching-only name server is used to provide name resolution client resolvers in a small, 
remote office with limited network bandwidth. A caching-only name server does not host any 
zone database files; therefore, 


Æ Network traffic responding to queries from other name servers will not be generated. 


@ Network traffic using supporting zone file updates will not be generated because a 
caching-only name server does not host any zone files. 


© Network traffic generated by client resolver queries will be reduced. When a caching- 
only name server resolves a query for a client resolver, the results are stored in the 
name server’s cache. The name server will use the information stored in cache to resolve 
other resolver queries. 


To create a caching-only name server, install the DNS service but do not configure any zones. 
Configure client computer’s TCP/IP properties to use the DNS server you configured for name 
resolution. 


Active Directory Integrated 


To create an Active Directory Integrated zone, you use the DNS interface and New Zone 
Wizard just as you would to create a standard primary or standard secondary zone. The option 
to create an Active Directory Integrated zone will be available if your DNS service is running 
on a domain controller. When you create an Active Directory Integrated zone, you view and 
manage the zone using the DNS tool. 


The zone is stored as a dnsZone container in Active Directory, and any resource records in the 
zone are stored as dnsNodes in the container for their zone, as shown in Figure 3.3. 


To view the zone and any resource records for the zone, do the following: 


1. From the Administrative Tools menu, open Active Directory Users and Computers. 
2. On the View menu, click Advanced Features. 


3. In the Active Directory Users and Computers console tree, expand System, and then 
expand MicrosoftDNS. The Active Directory Integrated zone will be listed. Click the 
zone you want to view, and the resource records will appear in the details pane. 
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Figure 3.3 Active Directory Integrated zone being viewed using Active Directory Users and 
Computers. 


Active Directory Integrated zones use a multiple master model, so any domain controller for a 
Windows networking domain that has the DNS service installed and the zone configured in 
DNS can manage a zone database. This provides fault-tolerance because there is no single 
point of failure for the zone as there is with a standard primary zone. 


You can configure a standard secondary zone, even if the primary zone is an Active Directory 
Integrated zone. Because the DNS service provided with Windows 2000 is RFC-compliant, you 
can configure any RFC-compliant DNS name server as a secondary server for an Active 
Directory Integrated zone. 


Reverse Lookup 


You can create an Active Directory Integrated reverse lookup zone that works in the same 
manner as an Active Directory forward lookup zone. As with the Active Directory Integrated 
forward lookup zone, the reverse lookup zone is stored in Active Directory, and standard sec- 
ondary in-addr.arpa zones can be configured to use the Active Directory reverse lookup zone 
for the master (see Figure 3.4). 
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Figure 3.4 DNS Manager with an in-addr.arpa (reverse lookup zone) displayed. 


Installing and Configuring the DNS Service 


When configuring DNS support for your network, you must decide how many servers will be 
needed to support a zone and which servers will perform what tasks before installing the serv- 
ice, and configuring the zones. The DNS service is available with any of the Windows 2000 
Server products. 


Installing the DNS Service 


You can install the DNS service as part of the operating system installation process, during 
the domain controller promotion process, or after the installation is complete. 


E To install the DNS service as part of the installation of the operating system, you select 
the DNS Service as an additional service to install and configure. 


@ To install the DNS service as part of the domain controller promotion process, you have 
the promotion wizard install and configure the DNS service, creating the zones needed 
to support Windows 2000 Active Directory. 


@ To install the DNS service after the installation of the operating system, you use 
Add/Remove Programs in the Control Panel, and click Add/Remove New Components. 
The DNS service is listed under Networking Services. 


After the DNS service is installed 


E Anew key is added to the Registry that defines the DNS service to the operating system 
HKEY LOCAL MACHINE\SYSTEM\CurrentControlSet\Services\DNS. 


@ Anew tool is added to the Administrative Tools menu DNS. 
WE Anew directory is created systemroot\system32\ DNS. 
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“| systemroot is a variable that is used to indicate the root directory of the Windows 2000 operating system. By default, the name 
= of this directory is Winnt. To use the systemroot variable in a command, you would place a % on each side of systemroot. 

| For example, to change directories to the root of the currently booted version of the operating system, you would type cd 

_. %systemroot% and then press Enter. 


Post-Configuration Tasks 


When you install the DNS service, the basic installation of the service is performed, and the 
previously listed items are installed. To configure the DNS server after the DNS service is 
installed, do the following: 


1. Open DNS from the Administrative Tools menu. 


2. Right-click the server icon in the console tree of the DNS tool and then click Configure 
the Server. 


The Configure DNS Server Wizard is started, as shown in Figure 3.5, allowing you to config- 
ure the server for operation in your specific network. 


Welcome to the venice | DNS 
Server Wizard 

This wizard helps you set up a DNS [Domain Name System) 
server and configure the server zones. 


A zone is a database that inks DNS names and related data, 
such az IP addresses or network services. 


To continue, click Nest, 


Figure 3.5 The Configure DNS Server Wizard enables you to configure a server for your 
network. 


The first question you must answer in the wizard is whether the DNS name server is the first 
DNS name server on your network. If you select Yes, the wizard will configure the name 
server as the root server for your network. 


A root server is the first DNS name server on your network, and is configured by the wizard 
with a zone named “.”. This zone represents the Internet’s root domain. In this manner, when 
more name servers are installed on your network and they perform an iterative query, the 
query will be sent to your network’s root server instead of to the Internet’s root-level name 
servers. Figure 3.6 shows the DNS tool for a server configured as a root server. 
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Figure 3.6 The DNS administrative tool of a server configured as a network root server. 


Creating a New Zone 


To create a new zone, open DNS from Administrative Tools, right-click the server on which you 
want to create the new zone, and click New Zone. The New Zone Wizard starts and guides you 
through creating a new zone. You can choose to create 


W An Active Directory Integrated zone (if you are creating the zone on a Windows 2000 
domain controller) 


M Standard Primary zone 
E Standard Secondary zone 


After selecting one of these three choices listed, you will be prompted to create a forward 
lookup zone or reverse lookup zone and then type the name of the zone. If you selected a stan- 


dard secondary zone, you will be prompted to provide the name and IP address of the server 
that will act as the master server. 


Before a secondary name server will receive any updates from its master name server, an NS 
record must be created for the secondary name server in the zone. To create an NS resource 
record in the zone, you would add the secondary name server from the primary name server to 
the Name Server tab found on the Properties page for the zone (see Figure 3.7). Each zone has 


its own Properties page, so you must add the name servers to the Name Server tab for each 
zone. 
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Figure 3.7 To add an NS resource record to a zone on a primary or Active Directory 
Integrated zone, add the name server to the Name Server tab on the Properties 
page for the zone. 


Client Resolvers 


In the past (and currently with most DNS servers), for a client computer to have a resource 
record added into a zone, the administrator for the DNS server had to manually add the 
record to the appropriate zone. With most networks, a DHCP server provides client computers 
on a network with an IP address that is leased for a given time. If DNS is the main name res- 
olution mechanism for the network, the client computers must have resource records that.are 
current in the DNS database so other computers on the network can locate them. 


To lower the amount of work required keeping zone information current, the dynamic update 
protocol was introduced into the RFC standards track. The dynamic update protocol allows 
client computers to register resource records in their zone. The Windows 2000 DHCP service 
can also be configured to update the DNS zone on behalf of the client. | 


Windows 2000 Clients 


Currently, the only resolver in the Windows suite of operating system products that has the 
capability to send update information to a Windows 2000 DNS server is Windows 2000. 
Figure 3.8 shows a Windows 2000 client updating the DNS zone after receiving an IP address 
from a DHOP server. The DHCP client/server configurations determine whether the client or 
server will be responsible for updating the DNS server information. 
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Figure 3.8 A Windows 2000 client updating the DNS zone after receiving an IP address 
from a DHCP server. 


When a Windows 2000 computer is booted, part of the startup process is to contact a DNS 
server to register its hostname and IP address. The TCP/IP properties can be configured to 
send the DNS server hostname and IP address registration data or, if the computer receives IP 
addressing information from a Windows 2000 DHCP server, the DHCP server can be config- 
ured to send the data to the DNS server. 


Windows NT 4.0 Clients 


Windows NT 4.0 (and previous versions of Windows NT) clients do not have the capability to 
send IP addressing information to a DNS server. There is some speculation that when Service 
Pack 7 for Windows NT 4.0 is released, it will provide the capability for a computer running 
Windows NT 4.0 to send dynamic update information to the DNS server. 


Currently, for a Windows NT 4.0 client to be able to take advantage of the dynamic update 
capability of a DNS server, the client computer must be configured to receive IP addressing 
information from a Windows 2000 DHCP server. The DNS zone update process is performed 
by the DHCP server, as shown in Figure 3.9. This is true of any Windows client computer that 
cannot update DNS zone information. 
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Figure 3.9 DNS zone information can be updated by a Windows 2000 DHCP server on 
behalf of a Windows client computer that cannot update zone information. 


Windows 9x Clients 


Windows 9x clients cannot send the DNS server registration information. For a Windows 9x 
client to be able to take advantage of the dynamic update capabilities of the DNS server, the 
9x client must be configured to receive IP addressing information from a Windows 2000 DHCP 
server. The DHCP server would then send the DNS the registration information on behalf of 
the DHCP client. 


There is an Active Directory-aware client for computers running Windows 9x that gives the 
Windows 9x client the capability to function in a Windows 2000 Active Directory networking 
environment, but it does not provide the capability to send update information to the Windows 
2000 DNS server. 


Non-AD-Aware Clients 


Non—Active Directory-aware clients do not have the capability to send dynamic update infor- 
mation to a Windows 2000 DNS server. For a computer that does not have the capability to 
send dynamic updates to a DNS server, the client must be a Windows 2000 DHCP server 
client, or resource records must be added to the DNS server manually. 
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Dynamic Update Configuration 


The capability of a Windows 2000 DNS server to accept dynamic update information is a con- 
figurable option that is disabled by default. To enable dynamic updates for a standard zone, do 
the following: 


1. Open DNS from the Administrative Tools menu. 
2. Right-click the zone you want to configure, and then click Properties. 
3. Under the General tab, set Allow Dynamic Updates to Yes. 


Figure 3.10 shows the Properties page of an Active Directory Integrated zones and the update 
options available. The options available are Yes (allow dynamic updates) and No (disallow 
dynamic updates). If the zone is an Active Directory Integrated zone, there is also an option to 
allow Only Secure Updates. 


updates 


Figure 3.10 You can configure a zone to allow or disallow dynamic updates. If the zone is an 
Active Directory Integrated zone, you can also configure it to allow only secure 
updates. 


PREPARING TO 
INSTALL DNS 


This chapter is designed to help you prepare and plan for a DNS implemen- 
tation in a Windows 2000 environment. This chapter provides development 
strategies, checklists, and some best practices. 


As you begin to develop a strategy for deploying DNS in a Windows 2000 
environment, the most important considerations are planning, documenta- 
tion, and communication. You should develop a plan that is functional for 
your total organization and is adaptable for future growth. You should also 
document all information as it relates to planning, development, and 
deployment. Many organizations fail to plan organizational structure and 
document it properly, which makes troubleshooting efforts much more diffi- 
cult. As you continue through this book, keep the issues of planning, docu- 
mentation, and communication in mind. 


-= Effective communication ensures that everybody, from the top to the bottom of an organization, is prop- 
___ erly informed. In addition, it is important to set the appropriate expectations regarding what the network 
can handle. 


Planning for a DNS Deployment 


Before you begin development of your DNS structure, you should review the 
basic concepts of DNS. (This book assumes that you are already familiar 
with DNS.) You should also review the organizational structure of the com- 
pany and obtain or create appropriate documentation and diagrams that lay 
out that structure. 
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Following are some of the areas where it is critical for you to develop a plan: 


E Namespace. Details the domain name standard naming convention you will implement 
for your domain and organization. 


M Zones. Details how you will divide your DNS domain name and network address space 
for forward lookup zones. 


E Reverse Lookup Zones. Details how you will divide your DNS domain name and net- 
work address space for reverse lookup zones. 


Æ Server Planning. Details how many servers you estimate you will need and where you 
will integrate them in your network. 

E Migrating Servers. Details how you will integrate or migrate your current DNS 
servers into your Windows 2000 DNS implementation. 

M@ Interoperability Issues. Details what, if any, interoperability issues you might have, 
together with contingencies for those issues. 


Namespace Planning 


Namespace planning involves determining why you want to implement DNS and what you 
expect to accomplish with DNS. For instance, if you are using DNS for name resolution and 
not for service location, another service, such as WINS, still needs to be used, and you must 
configure DNS to interoperate with WINS. If DNS is going to replace WINS for locating other 
services, you must configure all the clients on your network accordingly. 


If your organization already has a registered domain name, you need to decide whether you 
will use separate domain names for the internal and external network structure. Also, your 
network design and planning team might have already resolved some of the planning issues. If 
you do not have a registered domain name, you need to choose an appropriate name and regis- 
ter that name with the IANA, as covered later in this chapter. 


Some additional namespace planning considerations are as follows: 


@ Will you use DNS for a private network only, Internet communication, or a combination 
of both? 


mE Will you integrate DNS into your Active Directory structure? 

E What naming convention will you use for computers on your network? 

WE Will you provide separate namespaces for different organizational units within your 
organization? 


mM Is your organization large enough to deploy DNS, or should you use an ISP? 
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Choosing a Parent DNS Domain Namespace 


Before setting up your first DNS server, you should determine a suitable and unique parent 
DNS domain name and then register the name with the appropriate agency. 


Network Solutions, Inc. (NSI). Formerly known as InterNIC. You can register .com, 
.net, and .org addresses through NSI at http: //www.nsiregistry.net/. 


Internet Corporation for Assigned Names and Numbers (ICANN). 


http: //www.icann.org/. 
Internet Assigned Numbers of Authority (IANA). http://www. iana.org/. 


When choosing your parent DNS domain name, you need to consider several things: 


What name describes the entire organization? Consider a name that is generic 
enough to allow for future growth and expansion, but also distinct enough to easily iden- 
tify your company or organization. 

Is this parent DNS domain name for a private/internal network or for the 
Internet? Choosing a DNS domain name for use with the Internet can be tricky as a 
result of the vast number of names already in use. At NSI’s Web page, you can find an 
application that determines whether a name you specify is available. 


Will the organization use subdomain names to provide identities to specialized 
organizational units? You can combine your parent DNS domain name with organiza- 
tional names to form subdomain names. For example, books.collier.org could be a sub- 
domain of the collier.org parent DNS domain namespace. 


Choosing your parent DNS domain namespace is an important first step in the planning a 
DNS deployment in a Windows 2000 environment. 


Choosing Child DNS Namespaces 


When choosing your DNS namespaces, keep the following things in mind: 


W Characters in your name should conform to the Internet standard character set, which 


is comprised of those used in DNS host naming. (For a list of allowed characters, refer to 
RFC 1123.) 


If the network is migrating from a previous version of a Microsoft network operating 
system, your current computer names must conform to the NetBIOS naming convention. 
In Windows 2000, computers are identified in one of the following methods: 


W A NetBIOS computer name, used for backward compatibility and referred to as a 
down-level name, such as computer. 

W The full computer name, which is the computer name (host), and the DNS 
domain name for the computer, such as computer1.internal.newriders.com. 


mM An FQDN, designed for multihomed computers and comprised of the computer 
name (host) and a connection-specific domain name, such as computer1. 
newriders.com. 
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Æ Windows 2000 supports multiple namespaces. As a result, an organization can keep 
internal namespaces (for a private network) separate from external namespaces (for 
Internet connectivity). In addition, an organization can use a combination of internal 
and external namespaces. The use of internal and external namespaces is covered later 
in this chapter. 


DNS Namespace Planning for Active Directory 


Active Directory requires DNS as the locator service that resolves Microsoft domain, site, and 
service names to IP addresses. DNS is also involved in finding the logon service for a Windows 
2000 domain. 


You can set up DNS as part of the Active Directory installation process or during the promo- 
tion of the server to a domain controller using the dcpromo.exe command. 


For medium to large organizations, integrating DNS with Active Directory includes additional 
planning steps. For the smaller organizations that use a single domain model or single master 
domain module structure, planning and implementation should be straightforward, especially 
if the migration is occurring from an established DNS domain structure. 


Questions that need resolution before a full design of the DNS structure for Active Directory 
include the following: 


E How many Active Directory domains will be used? 
What is the naming structure for the Active Directory domains? 
Will the organization be implementing a private network using your DNS namespace? 


How will computer names be implemented? 


Zones 


Before talking about DNS zones, a brief definition of what a zone is and how it interacts with 
the domain model structure and an Active Directory namespace is in order. By definition, a 
zone is a portion of the domain namespace that is defined by the records that are stored within 
the zone database file. This can be compared to a set of numbers. A set of numbers is the por- 
tion of all the known numbers that are stored in the set. 


The zone database file contains information that maps host or FQDN names to IP addresses 
(forward lookups) and IP addresses to host or FQDN names (reverse lookups). As you begin 

to divide your namespace into zones, you should review current traffic patterns and forecast 
future traffic patterns to determine how you can best implement zones for your organizational 
structure. 
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DNS, by design, can help reduce broadcast packets within subnets and between local subnets, 
but it can also generate client-to-server and server-to-server traffic. This can be especially 
important on routed networks that span slow WAN connections, and it needs to be considered 
when planning a DNS implementation. Here are some things to consider about the types of 
traffic: 


WŒ Server-to-server traffic can be caused by zone transfers (full and incremental) between 
DNS servers and between DNS and WINS servers. (WINS lookup is enabled through 
DNS.) 


M Client-to-server traffic is increased by query resolution and dynamic updates. 


The key point is that Windows 2000 (especially Active Directory) is much more dependent on 
DNS for successful name resolution and interoperability than previous versions of Windows. 


You can configure three zone types in Windows 2000: 


M@ Standard Primary. Contains the master copy of the database file (stored as a text file). 


E Standard Secondary. A read-only replica of an existing zone database file (stored as a 
text file). 


E Active Directory Integrated. A Zone database file stored in Active Directory, which is 
updated during Active Directory replication. (DNS server must be on a domain con- 
troller.) 


__ Windows NT 4.0 uses primary zones and secondary zones. 


You can configure zones to perform zone transfers. This means that updates happen on one 
DNS server and then are copied to other DNS servers through a zone transfer. 


You can also configure zones to allow dynamic updates either from DHCP clients that have 
been configured to perform dynamic updates or from a Windows 2000 DHCP server. This can 
reduce administrator load for DNS. 


Replication of zone information is another consideration when designing zones. Windows 2000 
implements two methods for replication of zone information: 


wE Full Zone Transfer (AXFR). Replication of an entire zone database file. Most imple- 
mentations of DNS support AXFR to include Windows NT 4.0. 


M Incremental Zone Transfer (IXFR). Replication only of changes in the zone database 
file. This recent specification (RFC 1995) has not been widely implemented to date. 


You should also carefully consider implementing DNS name servers that support IXFR with 
DNS name servers that do not support IXFR because zone database transfers can be slow 
between Windows 2000 DNS servers and other DNS implementations. 
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Microsoft has also made the following recommended limitations when adding or extending 
zones: 


M Do not use more than 65,553 resource records in a zone. 


HM Do not load more than 1,000 zones on any DNS server. 


These recommendations are for the current implementation of Windows 2000 DNS. As DNS in Windows 2000 matures, you will be 
able to find updates through white papers and the Microsoft Knowledge Base. 


Reverse Lookup Zones 


The typical operation of DNS queries is to do a forward lookup query, which resolves a host or 
FQDN name to an IP address. DNS also provides a mechanism to resolve an IP address to a 
host or FQDN name. This is referred to as a reverse lookup query. 


DNS was not initially designed for this type of query. To handle reverse lookup queries, the 
in-addr.arpa domain was created. To create the reverse namespace in the in-addr.arpa domain, 
the octets of the IP address are reversed and then used to populate the reverse lookup zone. 
This reverse lookup zone is now part of the DNS specification. 


The same general considerations should be taken with the reverse lookup planning that is 
used with the zone planning. Zone planning deals with the conventional forward lookup 
queries. As an example, a reverse domain zone for a network ID of 131.107.0.0 would have 
an entry of 107.131 in the in-addr.arpa. 


Server Planning 


In the Windows NT 4.0 environment, one of the biggest concerns was, “Can our servers handle 
the load?” A quick review of systems and components adds value to the considerations in plan- 
ning a Windows 2000 DNS structure. 


There are four main subsystems in our computers that greatly impact server performance: 


E Memory 

M@ Processor 

@ Disk subsystem 

E Network subsystem 


These subsystems work interactively to provide complete functionality. If one subcomponent 
becomes a bottleneck, the whole system sees degradation in performance. The memory and the 
processor in a server are historically where most bottlenecks occur. 
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__ The minimum requirements for Windows 2000 server, as provided by Microsoft, are a Pentium 166MHz processor, 96MB of RAM, 
-and 1GB hard drive. Keep in mind these are minimum requirements to install Windows 2000. Actual requirements will be much 
higher. 


Memory 


Memory considerations entail the amount of physical RAM required and the way it will be uti- 
lized. Something to remember is that the operating system, network services (DNS, DHCP, 
WINS), network processes, and applications all use memory. The more services run on a par- 
ticular server, the more memory required. 


Different server configurations can also have an impact on how efficiently memory is utilized: 


W File and Print. The packet structure here is usually larger than that on an application 
server, and memory use is not as efficient because files and packets cannot stay in cache 
for any significant period. Adding memory can actually degrade system performance if 
other resources are not increased. You can get much greater performance by adding a 
combination of memory and additional processors and by making sure the amount of L-1 
and L-2 cache is comparable with the amount of RAM installed. An average file and 
print server performs well with 256MB of RAM and a single processor installed. 


The one exception to this is the Web server, which is considered part of the file server 
environment, though with active Web pages acts more like an application server. 
Smaller individual packets are actually transferred to create one larger Web page. 
Adding memory to a Web server is of great advantage. 


E Application. Packet structure here is usually made of smaller packets that tend to 
come more frequently. Adding memory to an application server can increase performance 
markedly because of the smaller packet sizes and the fact that information stays in 
cache much longer. Computers with multiprocessors can increase performance even 
more. Application servers realize greater performance with 512MB or more of RAM and 
multiple processors installed. 


E Domain controller. Packets here tend to be a combination of larger and smaller. You 
need to determine what is more important: client-to-server traffic or server-to-server 
traffic. Several settings can be made to help optimize performance. 


| Due to the potential resource overhead and multitasking in mid-size to larger organizations, DNS servers should be installed on a 
7 server that performs only DNS functions. Smaller organizations can get by with an internal DNS server and use their ISP’s DNS 
_. server for Internet access. 


Processor 


The processor’s main mission is to handle interrupt requests and to process information. In a 

32-bit environment, performance can be greatly enhanced by adding multiple processors. In a 
16-bit environment, simply upgrading the processor is adequate. Most of the major services of 
Windows 2000 perform some database function used to keep track of transactions. Because of 


this, the processor takes on a much larger role than the network of disk subsystems in system 
performance. 
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Disk Subsystem 


Read and write performances are the biggest concerns with the disk subsystem. Implementing 
RAID volumes and increasing capacity by adding additional disks helps to reduce storage- 
related problems for Windows 2000. 


Network Subsystem 


The network subsystem is the hardest to maintain and troubleshoot. Simple maintenance and 
troubleshooting techniques often include the following: 


E Load balancing. Resources can be offloaded to multiple servers or to make more 
resources available. 


M Segmentation. Segmenting the network can reduce bottlenecks in the network subsys- 
tem. By segmenting, you can reduce broadcast packets and redirect traffic to specific 
servers. You can accomplish segmentation by using bridges and routers or by adding 
multiple NICs and segmenting at the service or protocol level. 


HM Reduction of protocols. Minimize the number of protocols that are running on your 
network. Remove any rarely used protocols. 


After considering the load that will be placed on your DNS computer’s major subsystems by 
the tasks it will perform, you can continue server planning for your DNS implementation in 
Windows 2000. The primary considerations are outlined in the following section. 


Server Capacity Planning 


Server capacity planning involves considering a combination of hardware, volume of traffic, 
and number and size of services running. Questions that you need to resolve include the fol- 
lowing: 


E How many zones will the DNS server load and host, and how large is each of those 
zones? 


mM What is the volume of traffic that is expected to the server? How many client query 
requests will it handle? 


E Is the DNS server going serve as a member server or a domain controller? 


The answers to these questions help you determine how to configure your hardware. 


As stated earlier, all services use memory to function properly, and DNS is no different. 
Microsoft estimates that about 4MB of RAM is used to start the DNS server service without 
any zone records. For each resource record, an additional 100 bytes is used up. Each zone that 
is configured takes up memory as well. As you can see, for larger organizations, resources are 
at a premium. 
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| The figures stated previously do not indicate any limitations of DNS servers in Windows 2000. They are simply used as a reference 


Number and Placement of DNS Servers 


There are no specific recommendations regarding server placement. However, it is generally 
considered the best practice to place servers in a central location where easy access from the 
majority of clients is achieved. 


When considering the number of DNS servers that will be required to support an organization, 
consider the following: 


E Network topology. If the organization has a routed network with high-speed WAN con- 
nections between locations, consider using two DNS servers for all the sites. If the sites 
are connected by slower links, consider using multiple DNS servers placed at the various 
sites. 

@ Fault tolerance and redundancy. Always consider having at least two DNS servers to 
provide redundancy in case one server fails. 


E Zone transfers. Slow WAN links can present some problems for zone database trans- 
fers. Consider implementing cache-only servers in the remote locations. 


If you are unsure about how your plan will affect performance, use built-in tools available with 
Windows 2000, such as the system monitor and network monitor, to gather information about 
server health and network capacity. You should be familiar with these two areas before you 
implement DNS. 


Migrating Servers 


If you are currently using a DNS implementation in Windows NT 4.0 or the BIND implemen- 
tation, you can migrate it to Windows 2000. Three migration paths exist for migrating other 
versions of DNS to Windows 2000: 


E Upgrading a Windows NT 4.0 server running DNS to Windows 2000. 
M Moving zone files from an existing DNS server to the Windows 2000 DNS server. 


W Migrating zones using master-secondary zone transfer from BIND servers to 
Windows 2000. 


When migrating or copying zone files from a BIND DNS server to a Windows 2000 DNS 
server, you need to copy and rename any zone files or boot files created in BIND. 


Using the BIND boot file with Windows 2000 DNS servers has some limitations. There are 
several BIND boot directives that are not supported by Windows 2000. These are detailed later 
in this chapter. 
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Interoperability Planning for DNS 


The Windows 2000 implementation of DNS supports and implements the RFC specifications 
that concern DNS and are considered standards and some of the Internet-Draft specifications. 
This means that there is full interoperability with other DNS server implementations that are 
RFC-compliant. 


Microsoft has tested interoperability with the 4.9.7, 8.1.2, and 8.2 implementations of BIND. 
Despite this, there are some considerations to take into account if Windows 2000 DNS servers 
will interact with other DNS implementations. 


For Windows NT 4.0 DNS servers to coexist with Windows 2000 DNS servers, you need to 
ensure that the Windows NT 4.0 servers support SRV records. Windows NT 4.0 Service Pack 4 
provides that functionality. 


Zone transfers with BIND and other DNS server implementations can be slower than between 
two Windows 2000 DNS servers. Windows 2000 DNS uses a fast transfer method using com- 
pression (default method), which BIND and other implementations do not support. 


Keep in mind that when implementing DNS as part of Active Directory, you need to upgrade 
all BIND DNS servers to version 8.1.2 or later. 


Windows 2000 DNS servers also provide some enhancement options that you can implement 
as part of the deployment: 


E WINS forward and reverse lookups. Windows 2000 provides WINS resolution for 
backward compatibility with earlier Windows systems. WINS integration allows host- 
names to be resolved using a WINS server in the event that the DNS server is unable to 
resolve the name. 


= Dynamic integration with DHCP servers. DHCP services in Windows 2000 provide 
support for registering and updating DNS zone information for non-Windows 2000 
clients. This is covered in Chapter 6, “Post-Installation Configuration.” 


A Windows 2000 DNS server that will host Active Directory—integrated zones must be config- 
ured as a domain controller. The advantages of using Active Directory—integrated zones is that 
the zone updates are encrypted and occur as part of the Active Directory replication process, 
and there can be multiple master copies of the zone. This is because each copy of the zone can 
be edited on any of the DNS name servers hosting the Active Directory—integrated zone. One 
of the main points of concern is that the zone data might not always be completely synchro- 
nized because changes to the zone are made at any of the name servers hosting the zone. 


This section has given you an overview of many things that you, as an administrator or network 
developer, need to look at prior to deploying Windows 2000 DNS services. As with any network 
implementation, planning, planning, planning, and documentation are the key components in 
successfully designing, implementing, and maintaining a Windows 2000 network with DNS. 


There are many other issues to consider for meeting specific organizational needs. 
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Planning a Structure 


Generally, organizations have private namespaces and public namespaces. The private name- 
space is a portion that is not visible to the Internet and is considered internal. The public 
namespace is exposed to the Internet and is considered external. If your organization wants to 
have an Internet presence, you must plan your DNS namespace carefully. 


Remember that Active Directory naming follows the standard DNS format. Therefore, the 
Active Directory root domain must be unique throughout the DNS hierarchy (Internet) and 
each Active Directory domain must conform to the Internet domain naming rules. 


__ There should not be any duplication between internal names and external names for an organization. Duplication can lead to 
i errors in the name-resolution process. 


This section focuses on planning a namespace structure by using private/internal and 
public/external namespaces with Active Directory and DNS. Consider the advantages and dis- 
advantages of each of the following strategies for deploying DNS for Active Directory. 


Using a Previously Registered Domain Name for the 
Active Directory Root Domain 


This strategy provides administrators with the flexibility to use the same DNS name for inter- 
nal and external networks. 


Advantages of keeping a domain name include the following: 


W No additional name registrations with IANA. 
M Existing organizational DNS structure requires no changes. 


W Current DNS transfer zones remain the same. 


The disadvantages are the following: 


ŒE Currently implemented DNS servers might need to be updated. 
E Windows NT 4.0 DNS servers will need to be upgraded to NT Service Pack 4 (with sup- 
port for SRV resource records) or later. 


E BIND implementations must be upgraded to version 8.1.2 or later to conform to the 
Active Directory DNS requirements. 


If you do use the same namespace for your internal and external network, additional measures 
might need to be taken to secure the internal network from the external network. 
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Using a Subdomain of a Registered DNS Domain Name 
As the Active Directory Root Domain 


If you are trying to better secure your Active Directory, you might want to consider making the 
Active Directory root part of the subdomain. This can enhance security by eliminating the 
exposure of the Active Directory root domain to the Internet. This works because you configure 
the authoritative DNS server in the existing domain with a delegation record to the Active 
Directory DNS server in the subdomain. 


For example, your Active Directory root domain is called home.bobcollier.org, which is a sub- 
domain of bobcollier.org. The authoritative DNS server will reside in the bobcollier.org 
domain, which connects to the Internet. A delegation record is configured to point to the 
home.bobcollier.org subdomain, which is the Active Directory root domain. All inbound queries 
from the Internet go through the parent domain of bobcollier.org and then get passed to 
home.bobcollier.org. This configuration eliminates direct access of the Active Directory root 
domain to the Internet. 


The primary advantages are the following: 


M The Active Directory domain is segregated from Internet, providing security for the 
internal network. 


@ Existing servers from original registered DNS domains do not need to be upgraded. 
Delegation has been passed to the new domain; therefore, replication only needs to be 


done on the internal network. The existing server serves only as a presence to the 
Internet. 


The primary disadvantages are the following: 


E The namespace for Active Directory is longer based on the location of the Active 
Directory root server. Ideally, you want the Active Directory root server to reside at the 
secondary level. Here, because you have created a subdomain in which to place the 
Active Directory root server, you are at the third-level domain or child domain. 

E The new domain that has become the Active Directory root domain requires at least one 
DNS server and preferably two or more for fault tolerance and redundancy. 


Use a Reserved Private DNS Domain Name for the Active 
Directory Root Domain | 
You might decide to use a private DNS name that is not registered with NSI, ICANN, or 


IANA. Accomplish this by using the reserved first-level domain called .1ocal. Your Active 
Directory root domain becomes a second-level domain under the .local domain. 
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This .local domain cannot be registered on the Internet and should be considered for use 
when the following is true: 


M You don’t want a registered DNS name. 
W You do not plan to have a presence on the Internet. 


WE You want to provide security for your Active Directory root from the Internet by having 
different DNS namespaces. 


The advantages to this strategy include not having to register a domain name with NSI, 
ICANN, or IANA and being able to use any valid DNS name for the Active Directory root. 


Certainly, the biggest disadvantage of using the .1ocal reserved domain is that if you decide 
later that you want to have an Internet presence with a valid registered domain name, you 
have to completely reinstall the forest. A second disadvantage is that local hosts are not 
resolved on the Internet. 


Consider this option very carefully before deciding to deploy it. For larger companies that rely 
on the Internet, this option is not advisable. For small- to medium-sized organizations, use 
this option only if present and future Internet presence is not desired. 


Whether planning network structures or DNS namespaces, you need to plan for the future. 
Look at an organization closely to monitor growth in the near future and the need for a pres- 
ence on the Internet. 


An organization could also use a combination of the .1ocal reserved namespace and external 
FQDN namespaces by employing a firewall. 


There are two methods of deploying the Active Directory by using a firewall or proxy server. 
Both of these methods require careful planning and proper configuration to satisfy the follow- 
ing goals: 


W Allowing internal computers to resolve any name, internal or external, within the organ- 
ization 


W Allowing internal computers to resolve any Internet name 


E Protecting the internal network by exposing only a small, specific portion of the organi- 
zation’s namespace to the Internet 


W Allowing for future growth of an organization and maintaining a secure internal net- 
work while being fully functional across the Internet 


Achieving these goals can be challenging, but with proper planning and deployment, an organ- 
ization can maintain anonymity and still capture all the glory of the Internet. The following 
two sections detail these two methods, including configuration of internal and external DNS 
servers, placement of firewalls, and the advantages and disadvantages of each method. 
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Use of a Single DNS Name for Both Private/Internal and 
Public/External Networks 


If your organization has a registered DNS namespace, you might want to use it for both inter- 
nal and external domain namespaces. However, you must ensure that the internal network 
remains separate from the external network by implementing a firewall or a proxy server. 


In the simplest form, there are two DNS zones, one for each of the internal (private) and exter- 
nal (public) networks. The rest of the deployment becomes much more complicated. You need 
to make a decision: Do your internal clients need to get data from the Internet or just your 
company’s public data? The answer here dictates how you deploy your DNS servers. 


If you choose to use a single domain name for both internal and external namespaces, you 
must configure an internal DNS server with a local root and an external DNS server for host- 
ing your Internet presence. The disadvantage here is that users on the external network might 
not be able to connect to the internal network. 


Separating DNS Zones Using a Firewall 


If you want to prevent internal employees from accessing the Internet but you still want them 
to have access to data published on the external network, you need to mirror resources from 
the external network on the internal network. 


For example, assume that your Active Directory DNS namespace is collier.org, which is regis- 
tered with NSI. Your company has two Web servers, web1.collier.org and web2.collier.org, 
which are available to the public. You want clients on the internal network to have access to 
the information contained on these Web servers, but you do not want them to have access to 
the Internet. You need to create a duplicate of web1.collier.org and web2.collier.org and place 
them on the internal network (see Figure 4.1). 


The DNS servers on the external network require .sRv resource records that point to servers 
on the external network, whereas the DNS servers on the internal network have .SRV resource 
records that point to servers on the internal network. The network administrator has to make 
sure that .sRV records point to the appropriate resources. 


The internal network requires a private root for the private namespace. The root serves the same purpose as the top-level root 
-domain on the Internet. 


If you do opt for this method of deploying the Active Directory namespace, you must ensure 
that the mirrored data is synchronized, a task that can prove challenging. 
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Figure 4.1 Combining the use of two mirrored DNS zones, one internal and one external. 


Allowing Internal Clients Access to Internet Resources 

The second scenario allows internal clients access to the Internet. This method still requires 
two separate DNS zones for the internal and external networks. However, in this case the 
internal DNS server resolves names to the external resources. Using the same example as pre- 
viously, when a client queries for web1.collier.org or web2.collier.org, the query is resolved to 
the two Web servers on the external network and the connection attempt passes through the 


firewall (see Figure 4.2). 
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Figure 4.2 Allowing internal clients access to Internet resources. 


Using this method results in the following: 


E It eliminates the need for having mirrored resources on the internal network. 


HM .SRV resource records on the internal DNS server point to resources on the external net- 
work. 


Æ Resolution for internal resources is still handled internally. 
@ The administrator has to keep track of resource records on two DNS servers. 
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The biggest drawback to this is managing security because of the following: 


ŒE The network administrator has additional planning for firewall configuration. 


E The firewall must be configured to specify exactly what types of traffic from internal 
clients will be allowed through the firewall. 


Another thing that can be done is to configure a proxy server in conjunction with the firewall 
to provide a greater degree of security and control. Be aware that for internal clients to have 

full Internet access, the internal DNS servers must be configured to forward DNS requests to 
the external DNS servers for resolution. 


If the client needs to resolve the DNS name ww.microsoft.com/ntserver, the following steps 
take place (see Figure 4.3): 


1. The client computer (resolver) sends a query to internal DNS server. 


2. An internal DNS server (the server the client is configured to use for name resolution) 
forwards query through firewall to external DNS server. 
3. An external DNS server checks cache for entry. If no entry exists, the external DNS 


server forwards the query to the top-level root domain requesting the IP address of a 
name server for the .com domain. 


4, The top-level root server replies to external DNS server with list of .com servers to exter- 
nal DNS server. 


5. The external DNS server forwards query to .com server requesting information about 
microsoft.com. 


6. The name server for the .com domain replies with the address of microsoft.com to the 
external DNS server. 

7. The external DNS server forwards a query to the microsoft.com server requesting infor- 
mation about microsoft.com/ntserver. 

8. Aname server for the microsoft.com domain replies with the IP address of 
microsoft.com/ntserver to the external DNS server. 


9. The ww server, ntserver, is resolved, and the information is passed to the external DNS 
server. 


10. The external DNS server forwards information through the firewall to the internal DNS 
server. 


11. The internal DNS server forwards requested information to the client. 


12. The client attempts connection with microsoft.com/ntserver through the firewall. 


If the network has a proxy server that is configured to allow internal clients access to the 
external network, then the process is different. The proxy server should be configured with an 
exclusion list containing all external/Internet addresses. The proxy server must also be config- 
ured with the address of an assigned DNS server that resides on the external network. The 
next figure outlines the steps to resolve an external Internet name through a proxy server. 
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Figure 4.3 Resolving external namespaces from an internal client. 


If the client needs to resolve ww.microsoft.com/ntserver using a proxy server (see Figure 4.4), 
the following steps take place: 


1. The proxy client sends a request to the proxy server for microsoft.com. 


2. After the proxy server determines that the requested address is on the exclusion list, the 
proxy server checks the exclusion list and then forwards the request to the assigned 
DNS server on the external network. 

3. The external DNS server looks in the cache for the address; if the address is not in the 
cache, the request moves on to the .com domain. 


4. The top-level root server sends the address of the .com domain to the external DNS 
server. 


5. The external DNS server forwards the request to the .com domain looking for 
microsoft.com. 
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The .com domain sends the address of microsoft.com to the external DNS server. 


The external DNS server forwards the request to microsoft.com. 
microsoft.com resolves the query and replies to the external DNS server. 


@ 


O OM ID 


The external DNS server queries the ww server called ntserver and resolves the address. 


10. The external DNS server forwards the reply to the proxy server. 


11. After the proxy server has the IP address to the requested resource, it forwards the 
request to the resource (microsoft.com/ntserver). 


12. microsoft.com/ntserver replies to the request and sends information to the proxy server. 


13. The proxy server sends a response to the client. 
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Figure 4.4 Resolving Internet names through a proxy server. 


As you can see, the process is a little bit different. Using a proxy server in conjunction with a 
firewall can provide both functionality and security. 
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Using Different DNS Domain Names for Internal/Private 
and External/Public Networks 


This section discusses using different names for internal and external networks, which is the 
method recommended by Microsoft. This method distinguishes internal from external net- 
works and eliminates the requirement for having mirrored resources. More importantly, the 
internal network is not exposed to the Internet. 


The setup of dual zones is the same concept as before, except that with this method, you use 
separate names for internal and external networks. The external network uses the organiza- 
tion’s registered DNS namespace. The internal network uses the reserved .local namespace. 


For example, if collier.org is the domain namespace used for the external network, the name- 
space of the internal network is collier.1local. The local namespace cannot be registered on 
the Internet (see Figure 4.5). : 


Clients use the internal DNS server to resolve addresses on the internal network. 
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Figure 4.5 Resolving internal addresses on a private network. 
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If a client needs to access data on an SQL server that has a host name of sql.collier.local, 
the resolution process would be as follows: 


1. 
2. 


3. 


The client sends a query for sql.collier.local to the internal DNS server. 


The internal DNS server resolves sql.collier.local to an IP address and then sends the 
result to the client. 


The client attempts to connect with sql.collier.local. 


This is very basic and efficient resolution on the internal private network. 


For client access to Internet resources, configure the internal DNS server to forward requests 
for the Internet to the external DNS server. Clients can also be configured through a proxy 
server. 


If a client needs to resolve ww.microsoft.com/ntserver, the query process is as follows: 


1. 


10. 
11. 


The client sends the query for microsoft.com/ntserver to the internal DNS server. 


The internal DNS server forwards the query through the firewall to the external DNS 
server. 


The external DNS server checks the cache for entry; if no entry exists, the external DNS 
server forwards the query to the top-level root domain looking for the .com domain. 


The top-level root server replies to the external DNS server with a list of .com servers. 
The external DNS server forwards the query for microsoft.com to a .com server. 
The .com server replies to the external DNS server with the address of microsoft.com. 


The external DNS server forwards the query for microsoft.com/ntserver to the 
microsoft.com server. 


The microsoft.com server replies to the external DNS server with the address of 
microsoft.com/ntserver. 


The external DNS server forwards the information to the internal DNS server through 
the firewall. 


The internal DNS server forwards requested information to the client. 


The client attempts to connect with microsoft.com/ntserver through the firewall. 


If a client wants to resolve ww.microsoft.com/ntserver through a proxy server, these steps are 
followed: 


1. 
A; 


The proxy client sends a request for microsoft.com to the proxy server. 


After the proxy server determines that the requested address is on the exclusion list, the 
proxy server forwards the request to the assigned DNS server on the external network. 


The external DNS server looks in the cache for the address; if the address is not in the 
cache, the request moves on to the .com domain. 
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The top-level root server sends address of the .com domain to the external DNS server. 
The external DNS server forwards the request for microsoft.com to the .com domain. 
The .com domain sends the address of microsoft.com to the external DNS server. 

The external DNS server forwards the request to microsoft.com. 

microsoft.com resolves the query and replies to the external DNS server. 


Oo ID Tp 


The external DNS server forwards the reply to the proxy server. 


10. After the proxy server has the IP address of the requested resource, it forwards the 
request to the resource (microsoft.com/ntserver). 


11. microsoft.com/ntserver replies to the request and sends information to the proxy server. 
12. The proxy server sends the response to the client. 


The biggest disadvantages for this deployment method are the following: 


mM It can be confusing to clients trying to access internal resources from the Internet. 


H Internal resources cannot be accessed from the Internet using the internal name of 
. local. 


As you can see, there are many different ways to configure the Active Directory namespace. 
The right way is dependent on the needs of the organization. No two organizations set up 
Active Directory DNS zones the same way. Planning, documentation, and effective communica- 
tion are the keys to successful deployment. 


One thing to keep in mind regarding the implementation of DNS in the Active Directory is 
that many organizations use BIND servers, especially on external networks. Can you still use 
the BIND implementation with the new Active Directory DNS structure? Yes, you can, but you 
have to remember that Windows 2000’s DNS implementation in Active Directory uses secure 
updates with other Windows 2000 DNS servers. You do not have secure/encrypted updates 
with the BIND servers. 


Clients can be configured to update the Active Directory DNS server using the dynamic update 
protocol, and the BIND server can be set up to pass delegate authority down to the Active 
Directory Windows 2000 DNS server. , 


You can also configure the Active Directory DNS server not to update the BIND servers. This 
is especially useful if you are going to maintain mirrored sets of resources for the internal and 
external networks. There would be no need for updating the BIND server on the external net- 
work. 


The DNS server that is integrated into Active Directory has to be on a domain controller, and 
it uses a multimaster replication model. All replication is done using encrypted updates. 
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Registering a Domain Name 


After you have selected the top-level domain name, you must register it through the Network 
Solutions, Inc. (NSI) Registry Web site (http: //ww.nsiregistry.net) or through one of the 
authorized registrars at the Internet Corporation for Assigned Names and Numbers (ICANN) 
Web site (http: //www.icann.org). 


At one of these sites, you can go through the process of checking to see whether the name you 
want to register is already taken and then registering an available name. The process can be 
done online through secured servers, or you can contact the organization directly. Currently, 
they are only accepting credit card payments. 


Some of the information required to register includes the following: 


Company name 

Address 

City, state, zip code 

Telephone number 

Contact information 

Contact email address and phone number 
Billing contact information 

Billing contact email address and phone number 


Name that you are trying to register 


Different registrars have some different information that they need from you. 


Keep in mind, you can either register your DNS top-level name or simply reserve it for a later 
time. The steps and payment are a little different for each. 


Reserving a Top-Level Domain Name 


Reserving a top-level domain name involves many of the same steps as registering. Keep in 
mind that reserving a name does the following: 


W Requires no technical information about the company 

Secures a Web address for future use 

Provides either a dot com biz card or “under construction” Web page 
Enables you to access value-added services and special promotions 
Costs $119.00 for the first two years 


Reserving a top-level domain name ensures that you will have access to the name when your 
business is ready to start or ready for a presence on the Internet. Shortly before the end of the 


70 Chapter 4 Preparing to Install DNS 


two years is up, the registrar invoices you (billing contact) for the next year’s fees (around 
$60.00). If you fail to pay, you lose the reservation of the domain name and it becomes avail- 
able to the next bidder. 


Registering Your Top-Level Domain 


When you decide to register your top-level domain name, you go to the appropriate authorized 
registrar and begin the registration process, which includes the following: 


WE Provide all technical information about your company addressed earlier 


E Registration becomes active after your payment has been verified and the information 
is sent to NSI and registered 


@ Cost for each address is $70.00 for two years (not including any service fees from 
your ISP) 


After your name has been fully registered, you need to visit the registrar again to make final 
arrangements for who will host the actual Web page and whether you want them to provide 
any links to other Web pages. The registrar provides many services that you can take advan- 
tage of if you need to. 


When your two years of registration are nearing an end, the registrar invoices the billing con- 
tact for the next year’s payment of $35.00. Failure to pay the fee within a certain period can 
result in forfeiture of registration and loss of all registration fees. 


The following is a price listing for different domain names: 


W .com. $70.00 for 2 years, $35.00 for each year thereafter 

.net. $70.00 for 2 years, $35.00 for each year thereafter 

.org. $70.00 for 2 years, $35.00 for each year thereafter 

.co.uk. $79.45 (49GBP) for two years, $38.91 (24GBP) for each year thereafter 
.ky. $199.00 per year 


Many more country code listings can be registered. 


The process for registering top-level domain names has changed over the course of the last two 
or three years. InterNIC used to be the sole entity for all registrations. Now, three primary 
agencies deal with the registration and maintenance of the Internet. However, there are still 
some fine points that need to be worked out between the organizations. 


Registering an in-addr.arpa Domain Name 


For larger organizations, you can register your reverse lookup zone with the American 
Registry for Internet Numbers (ARIN). The Web page where you can gather information and 
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begin the registration process is http://ww.arin.net. To look at the template, refer to 
http: //www.arin.net/templates/inaddrtemplate.txt. 


The in-addr.arpa provides a mechanism for resolving IP addresses to hostnames or FQDN. 
Many applications use hostnames as a means for authentication. To provide these services, 
there is the in-addr.arpa domain. For small to medium companies, it is best to let your ISP 
handle this for you. They will already have the knowledge to accomplish this; in fact, they 

probably already have this in place. 


The fees for ISPs are as follows: 


Small. $2,500.00 per year 

M Medium. $5,000.00 per year 
E Large. $10,000 per year 

E Extra large. $20,000 per year 


The fees for individuals are as follows: 


Small. $2,500 per year 
Medium. $5,000 per year 
E Large. $7,500 per year 


M@ Extra large. $10,000 per year 


As you can see, this can be expensive for smaller organizations. If you have an ISP that will 
host your namespace, use them as the in-addr.arpa registrar. When registered with ARIN, it 
becomes your responsibility to keep track of when payments are due. If you fail to make a pay- 
ment (they will not remind you), you will forfeit the registration and all monies paid in. 


Registration of domain names is a crucial step in the deployment process for the Active 
Directory namespace. If your organization is looking for a presence on the Internet, registra- 
tion of the public namespace is crucial. Be careful about registering the internal part of the 
namespace. Registering the internal structure of the namespace makes you more vulnerable to 
security risks. Remember that the private reserved domain (.local) cannot be registered on 
the Internet. 


INSTALLING DNS 


This chapter provides the information and steps necessary to install the 
Windows 2000 implementation of DNS. The chapter starts with the four 
methods for installing DNS and continues with information on creating the 
various types of name servers (Root, Primary, Secondary, Cache-Only, and 
Active Directory—Integrated). 


Installing DNS in Windows 2000 is relatively easy. However, it is important 
to understand that detailed planning and documentation are imperative. If 
you plan your deployment strategy well, implementation should be quick 
and painless. 


The figures in this chapter provide a graphical representation of the differ- 
ent installation processes and enable you to focus more on planning and 
documentation as opposed to the implementation phase. I cannot stress 
enough the importance of planning and documentation for Windows 2000 
deployment. The percentage of planning and documentation versus imple- 
mentation should be 85 percent to 15 percent. 
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Installation of DNS 


After you plan the Active Directory and DNS server implementation, you are ready to proceed 
with the installation process. First, review the TCP/IP settings for the server on which you 
will install DNS: 


1. In the Internet Protocol (TCP/IP) Properties dialog box, check that the following are 
specified (see Figure 5.1): 


@ A static TCP/IP address 
@ A subnet mask 
HM A default gateway (if in a routed network) 


Figure 5.1 The TCP/IP Properties Dialog Box enables you to review server settings. 


2. In the Internet Protocol (TCP/IP) Properties dialog box, in the Advanced box, configure 
the following (see Figure 5.2): 


E Host 
HM Domain Name suffix 
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Figure 5.2 The Advanced box of the TCP/IP dialog box enables users to adjust the Domain 


Name suffix. 


After you have verified these settings, you are ready to begin the installation. Several tasks 
involved with installing the Windows 2000 implementation of DNS occur automatically and 
without rebooting. The installation process does the following: 


Starts the service automatically 


Installs the DNS console, used to manage both local and remote DNS servers 
Adds a shortcut for the DNS console to the Administrative Tools menu 


Updates the Registry with a DNS server service subkey: 
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DNS 


Creates a DNS folder in the system32 directory structure and adds the following data- 
base files: 


domain_name.dns (zone database file) 
z.y.X.wW.in-addr.arpa (reverse lookup file) © 

cache.DNS (contains records of root servers on Internet) 
Boot (file controlling how DNS starts) 


The boot file is an optional file in Windows 2000 and Windows NT 4.0 because the startup parameters are stored in the Registry. 
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There are four basic ways to install DNS in Windows 2000: 


M@ During Windows 2000 installation 
Using the Windows 2000 Configure Your Server Wizard 
Using Add/Remove Programs in Control Panel 


Using the DCPROMO.exe command 


I will first provide an overview of the installation process using each of the four methods men- 
tioned previously. Then, I will discuss installing the different types of DNS server configura- 
tions: 

HM Root Name Server 
Primary Name Server 
Secondary Name Server 
Caching-Only Name Server 


Active Directory—Integrated Name Server 


Installing During Windows 2000 Installation 


To install the DNS server service during installation of Windows 2000, you can select 
Networking Services on the Windows Components page and then click Details. In the Details 
window, select the Domain Name Server (DNS) check box. 


This method is not advocated by many because it adds potential problems to the installation of 
Windows 2000. It is best practice to install most of your services after you have completed the 
initial installation of Windows 2000. This way, you ensure that you can at least install the 
operating system successfully. The more components or services that you install during instal- 
lation, the more difficult it becomes to troubleshoot problems should they arise. 


Installing with the Windows 2000 Configure Your 


Server Wizard 


A second way to install DNS is by using the Windows 2000 Configure Your Server Wizard 
(see Figure 5.3). This wizard appears automatically when you log on for the first time after 
installing Windows 2000. (You can configure this window to pop up each time you log on 

to your Windows 2000 server by checking the Show This Screen at Startup check box.) 
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Figure 5.3 The Windows 2000 Configure Your Server window. 


In the Windows 2000 Configure Your Server wizard, select Networking and then select DNS. 
Next, select Set Up DNS to start the DNS installation process (see Figure 5.4). 
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Figure 5.4 The Networking DNS window. 
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A Windows Server Setup—Installing DNS Server status window appears, followed by an 
Insert Disk dialog box prompting you for the Windows 2000 server CD-ROM. After you insert 
the Windows 2000 Server CD-ROM and select OK, the files are copied, and installation begins. 
This should take only a short while, depending on the configuration of your hardware. 


After this process is finished, you should verify that all the components have been configured 
for the DNS server service: 


M Verify that a DNS shortcut has been added to the Administrative Tools menu (see 
Figure 5.5). 
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Figure 5.5 Click Start, Programs, Administrative Tools, DNS from the Windows taskbar to 
verify the DNS shortcut. 


E Verify the DNS server service has been started by using the Services Management 


Console (see Figure 5.6). (Click Start, Programs, Administrative Tools, Services, DNS 
Server. ) 


E Open the DNS Console using the shortcut in Administrative Tools menu (see 
Figure 5.7). 


ŒE Open the Registry and verify the following subkey has been added. Click Start, Run 
and then type regedt32 (see Figure 5.8): 


HKEY LOCAL _MACHINE\System\CurrentControlSet\Services\DNS 


mM Use Windows Explorer to verify the creation of the DNS folder structure in the 
Ssystemroot%\system32\ directory. 
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Figure 5.7 The DNS Console window. 
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DependOnSenice : REG -MULTI SZ- Tcpip Afd Net8T RocSs NTL 

_ |Description: REG_SZ: Answers query and update requests for Domi 
DisplayName -REG SZ: DNS Server 
ErrorControl : REG_DWORD : 0x1 

{|ImagePath: REG_EXPAND_SZ: %SystemRoot%\System32\dns.exe 

ObjectName : REG_SZ:LocalSystem 
Start: REG_DWORD : 0x2 
Type : REG_DWORD.:: 0x10 


Figure 5.8 Viewing the DNS Registry Entry. 


After you have successfully installed DNS, you can create the zone files required for your 
implementation. These are talked about in Chapter 6, “Post-Installation Configuration.” 


Installing DNS with Add/Remove Programs in Control 
Panel 


To install the DNS server service after installing Windows 2000 server, you can use 
Add/Remove Programs in Control Panel. 


To begin the installation, open Control Panel and then double-click the Add/Remove Programs 
icon. This launches the Add/Remove Programs window (shown in Figure 5.9). 


From this window, select the Add/Remove Windows Components button to open the Windows 
Components Wizard window. Select Networking Services and then click the Details button to 
open the Networking Services window. Select the Domain Name System (DNS) check box, 
click OK, and then click the Next button. The Configuring Components Wizard window 
appears and shows a progress bar toward completion. When the installation is complete, click 
the Finish button to close the window. 


Add/Remove Programs in Control Panel has several improvements over previous versions of 
Windows. It provides greater functionality to both administrators and users alike. 


Installing with the Windows 2000 Configure Your Server Wizard 


Currently installed programs: 


| Ea Adobe Acrobat 4.0 Sice 


Cele here For support information, sed 
sed in 


To change this program or remove it from your computer, click 
Change of Rerniove, 


_ &F Microsoft Office 2000 Premium 
_ ES] NetShield NT v4.0.2 (Licensed) 


_ Pi Picture Navigator 

| Presto! ImageFollo LE 
E Presto! Mr. Photo 
ek Presto! PhotoAlbum 

0 Wiz 


Add/Remove Windows 
Components button 


Figure 5.9 Add/Remove Programs window enables users to modify their installation of 


Windows 2000. 


Installing DNS Using DCPROMO. exe 


The DCPROMO.exe command launches the Active Directory wizard. To install Active Directory, 
however, you must first have the DNS server service installed. During the installation of 
Active Directory, the Active Directory wizard prompts you to install DNS. The DCPROMO. exe 


eccasicnall 


1471/1995 
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command is primarily used for installing and configuring Active Directory; however, you can 


use it to install DNS at the same time. 


To begin the process, click Start, Run and type DCPROMO. exe. 


After a couple of seconds, the Welcome to the Active Directory Installation Wizard page 


appears. Click Next to continue. 


The Domain Controller Type page appears, which you can use to specify the role of domain 


controller. The two roles are the following: 


W Domain controller for a new domain, which enables you to create a new child domain, 


new domain tree, or new forest 


W Additional domain controller for an existing domain 
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| These are Active Directory settings and are not part of the scope for this book. | include them here only for the purpose of show- 
| ing how to install DNS using the DCPROMO.exe command. 


Select the appropriate domain controller type and click Next. The Create Tree or Child 
Domain page appears, which you can use to create a new domain tree or a new child domain 
in an existing domain tree. Select the appropriate selection for this server and click Next. The 
Create or Join Forest page appears, in which you can specify to create a new forest or join a 
forest. Make your choice and click Next. The New Domain Name page appears. Specify the full 
DNS name for your domain or server and click Next (see Figure 5.10). 


New Domain Name ERE 
Specify a name forthe new domain. 


l dns. bobcollier.org 


Figure 5.10 Enter the full DNS name for your domain/server on the New Domain Name 
page. 


The NetBIOS Domain Name page appears, showing the NetBIOS name that allows earlier 

versions of Windows to interact with the Windows 2000 server. You can accept the selected 

name or provide your own. Remember, the NetBIOS name is limited to 15 characters. Click 
Next, and you finally get to the part that pertains to you: the Configure DNS page. 


Because you have not installed DNS yet, you are prompted to install DNS. You have two 
choices: Install and configure DNS on this server or install and configure DNS yourself. If you 
choose to configure DNS manually, Active Directory is not enabled until DNS is available. It is 
advisable to choose to install DNS on this server. Select Yes and then click Next to continue. 
The final window is the Summary window (see Figure 5.11), which identifies all the selections 
that you have made. It is wise to double-check your options before continuing. Click Next to 
start the installation process. 
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“Review and confirm the options you selected. 


Figure 5.11 Summary window of the Active Directory Installation Wizard. 


Regardless of which method you choose, Windows 2000 makes installation easy. The remain- 
der of this chapter deals with configuring specific types of servers and their implementation in 
a Windows 2000 environment. 


Installing a Root Name Server 


Historically speaking, root name servers are authoritative for each of the top-level domains. 
By definition, a root server contains the resource records for all the top-level name servers in 
the domain namespace (for example, the .org domain). Each of the top-level name servers con- 
tains the resource records for the second-level name servers (for example, the bookcollier.org 
domain). Root name servers are where Internet resolution begins. In fact, if the Internet root 
servers were unavailable for an extended period of time, resolution on the Internet would fail. 
It has been estimated that the top-level root name servers handle thousands of queries per 
second. By default, root name servers on the Internet are listed in the cache.dns file as shown 
in Figure 5.12 (also called root hints) on the root name server. 


In Windows 2000 DNS implementation, you should configure a root name server if either of 
the following is true of your intranet: 


© Itis not connected to the Internet. 


M It connects to the Internet through a proxy server. 
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Figure 5.12 The cache.dns file (root hints) showing the root name servers for the Internet. 


Usually, root name servers are external to an organization; that is, they use a higher-level 
DNS root name server for resolution. You should consider whether your organization needs to 
configure a root name server. Midsize to smaller organizations typically might not need the 
hassle and additional overhead of configuring a root name server. These organizations can use 
the ISP that provides service or the parent secondary-level or top-level domain namespace for 
resolution. If an organization wants or needs a root-level server, they can configure their 
server to become a root to provide resolution up to the top-level domains. 


For organizations that are not connected to the Internet, a root name server does not need a 
cache file because there is no resolution to the Internet. You can edit the boot file to remove it. 


If you are connecting to the Internet through a proxy server, you can set up a root name server 
as normal and the proxy service handles translation and connections to the Internet. 


The two ways to configure a root name server are performed through the DNS Server 
Configuration Wizard, which is launched the first time you open the DNS console. The wizard 
collects setup information, after which you can specify the following information: 


E Root Server. Enables you to create a root server or use an existing DNS server on the 
network (see Figure 5.13) 
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Figure 5.13 The Root Server window dialog box enables you to seleċt an existing server or 
another server on the network. 


@ Forward Lookup Zone. Is a name-to-address database that helps computers translate 
DNS names into IP addresses and provides information about available services 


E Zone Type. Provides you with three different ways to obtain and store zone information 
of forward lookup zone: 


W Active Directory—Integrated. Stores zone in Active Directory allowing secure 
updates and integrated storage 


E Standard primary. Stores master copy of zone information 


W Standard secondary. Creates a copy of an existing zone; provides load balanc- 
ing and fault tolerance 


E Zone Name. Is the name of the zone (for example, home.bookcollier.org) 


Zone File. Creates a new zone file based on the zone name or uses an existing zone file 


E Reverse Lookup Zone. Is a database that helps translate IP addresses into DNS 
names (for example, 10.0.0.10 might be translated to home.bookcollier.org) 


W Zone Type. Provides three different ways to obtain and store zone information of 
reverse lookup zone: 


M Active Directory—Integrated. Stores zone in Active Directory, allowing secure 
updates and integrated storage 


E Standard primary. Stores master copy of zone information 


E Standard secondary. Creates a copy of an existing zone; provides load balanc- 
ing and fault tolerance 
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Æ Reverse Lookup Zone ID or Name. Creates the reverse lookup zone file (for example, 
inputting the Network ID 10, which creates a zone called 10.in-addr.arpa) 


Æ Zone File. Creates a new zone file based on the zone name or uses an existing zone file 


This completes the installation of the root name server. The console displays the root (“.”) zone 
and the “org” zones, as well as the reverse lookup zone for your zone (shown in Figure 5.14). 


DNS a) Forward Lookup Zones 
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Figure 5.14 This is the DNS console of root name server. 
Setting up a root name server is only part of implementing DNS. You can also set up four 


additional types of name servers as part of the root domain server or separately: 


@ Standard Primary Name Server 

@ Standard Secondary Name Server 
E Caching-Only Name Server 
E 


Active Directory—Integrated Name Server 


These name servers are discussed in the following sections. 
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Installing a Primary Name Server 


The primary server has the master copy of a zone database and is authoritative for its domain 
namespace. The master copy is a read/write version of the database that is stored as a text file 
in the %systemroot%\system32\dns file structure. The file should be the zone name followed by a 
“.” and the file extension “dns,” as in the following example: home.bookcollier.org.dns. This 
allows an administrator to administer and maintain the primary zone file for the server that 


you created the zone on. This type of server is also referred to as a master server. 


In Windows 2000, you can use primary name servers as standard primary zones or primary 
zones integrated with Active Directory. There can be only one primary server that hosts and 
loads the master copy of any single zone. For this reason, the standard primary zone is consid- 
ered a single point of failure; that is, no dynamic updates can be made to the zone. This should 
not affect queries made for names belonging to the zone, as long as secondary servers are 
available. The secondary name servers have a read-only copy of the master database. 


To install a primary server, follow these steps: 


1. Open the DNS console and select the server that you want to configure as a primary 
server. On the Action menu, select New Zone to launch the New Zone wizard, and click 
Next to continue setup. 


2. The Zone Type page appears, on which you can choose Standard Primary, Standard 
Secondary, or Active Directory—Integrated (only if Active Directory is installed in the 
enterprise). For the primary name server, select Standard Primary and click Next (see 
Figure 5.15). 


¿i Active Directory is grayed out in Figure 5.15 because the DCPROMO command has not been run on this server. 


3. The next window prompts you regarding the type of zone you want to configure: 
Forward Lookup Zone or Reverse Lookup Zone. 


Remember that the forward lookup zone resolves IP addresses to domain names and the 
reverse lookup zone resolves domain names to JP addresses. For the primary name 
server, you will want to configure at least a forward lookup zone and then click Next. 


4, The Zone Name page appears, prompting you for a zone name. Choose an appropriate 
name and click Next. 


5. The Zone File page appears, prompting you to select either Create a New File with This 
File Name or Use This Existing File. If this is the first zone, use the create new file 
option as shown in Figure 5.16 and click Next. 


6. On the Completing Installation page, select Finish to create the zone. 
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Figure 5.15 The Zone Type dialog box used for selecting Standard Primary, Standard 
Secondary, or Active Directory—Integrated. 


{web,home.bobcollierorg.dns 55i: 


Figure 5.16 The Zone File window dialog box used to accept the zone filename or use a 
pre-existing zone file. 


After you have created the primary server and configured the primary zone, you will see the 
new zone with a Start of Authority record (SOA) as well as the Name Server record (NS). Now 
that this is complete, you can add additional records for your zone of authority. 
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Installing a Secondary Name Server 


A secondary name server, also referred to as a slave server, pulls its information from a master 
server. Often, the master server is the primary name server that has authoritative control 
over the zone, but it does not have to be. When a secondary server initializes, it contacts the 
master server and pulls the zone data—called a zone transfer. After the initial zone data has 
been pulled, future updates are handled when the primary name server notifies the secondary 
name server of changes. This causes the secondary name server to connect to the master name 
server and pull the zone information. 


At a minimum, each organization using DNS servers should have two DNS servers, a primary 
and secondary. Secondary name servers provide load balancing by handling name queries and 
taking a load off the primary name server. As for the fault tolerance and redundancy, in the 
event that the primary name server should become unavailable, the secondary name server 
can provide name resolution. 


Now, I need to clarify how it is able to provide name resolution and for how long it can provide 
name resolution. This is important to know because the SOA resource record from the primary 
server determines how long the secondary server is able to provide resolution to queries. 


Secondary servers pull zone information from some master server (assume that it is the pri- 
mary master) through a mechanism called a zone transfer. When the secondary server first 
initializes, it pulls the SOA and the NS resource records from the master server and uses 
these records to perform name-query resolution and zone transfers. 


The SOA resource record includes several pieces of information (shown in Figure 5.17). 


@ Serial number. The revision number for the zone file. Each time a record is added or 
updated, this number is incremented by one. This enables the secondary name server 
to decide whether it needs to do an Incremental Zone Transfer (IXFR) or a Full Zone 
Transfer (AXFR). Obviously, you would like to have the incremental transfers over the 
full zone transfers. 


E Primary server. The hostname for the primary DNS name server for the zone. 


E Responsible person. The email address of the individual who is responsible for main- 
taining the zone. 


M@ Refresh interval. The time that a secondary name server waits before querying the 
primary master to renew its zone information. After the refresh interval has expired, the 
secondary server contacts the primary master server to request the SOA of the primary 
master server. After the SOA has been retried, the secondary name server compares the 
serial number of the SOA from the primary master with its own SOA resource record. If 
the serial numbers are different, a zone transfer is requested by the secondary name 
server. The default value is 900 seconds, or 15 minutes. 


E Retry interval. The time a secondary name server waits before retrying a failed zone 
transfer. The default time is 600 seconds, or 10 minutes. 
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E Expire interval. The time before a secondary server stops responding to queries after 
a failure to renew or update the zone information. The secondary server considers the 
data it stores to be inaccurate. The default time for this value is 86,400 seconds, 1 440 — 
minutes, or 24 hours. 


E Minimum TTL. The minimum Time-To-Live value applied to all resource records with- 
out an individually specified TTL. The default value is 3,600 seconds, 60 minutes, or 1 
hour. 
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Figure 5.17 Start of Authority (SOA) Resource Record property page for your DNS Server. 


Now for the really important information as it pertains to the secondary server and providing 
fault tolerance. I mentioned incremental zone transfers versus full zone transfers. Windows 
2000 has the capability to pull incremental information, whereas earlier versions of Microsoft’s 
DNS implementation (Windows NT 4.0) could perform only a full zone transfer. The incremen- 
tal zone transfers (IXFR) are a recent, RFC-defined implementation of DNS. For additional 
information, refer to RFC 1995. 


The installation of a secondary name server is similar to the primary name server. Here are 
the steps: 


1. Open the DNS console, select the server on which you want to install the secondary 
zone, select Action, New Zone. 


2. The Welcome to the New Zone Wizard window appears; click Next. 
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3. This brings up the Zone Type page, on which you can choose Standard Primary, 
Standard Secondary, or Active Directory—Integrated. Select Standard Secondary and 
click Next. 


4. The next page gives you the option of configuring a Forward Lookup Zone or Reverse 
Lookup Zone. Select Forward Lookup Zone and click Next. 


5. The Zone Name page appears, prompting you for the name of the forward lookup zone. 
Type the name of the primary zone (for example, web.home.bookcollier.org) and click 
Next. 


6. Next, the Master DNS Servers page appears, prompting you to specify DNS servers 
from which you want to copy the zone (see Figure 5.18). You can browse for a server, or 
you can type the IP address of the DNS server. After you have selected the DNS server 
from which to pull the zone information, click Next, and then click Finish in the next 
window. 


| Master DNS Servers 
The zone is copied from one or more DNS-servers: = 


Figure 5.18 The Master DNS Servers configuration window allows you to specify from 
which servers you want to copy zone information. 


7. After this is configured, you should see the new zone in the DNS console. After a couple 
of minutes, you see the resource records appear in the zone. Notice that the SOA and NS 
records are from the primary name server that you specified (seen in Figure 5.19). 


That completes the initial installation of the secondary name server. For additional configura- 
tion, see Chapter 6, “Post-Installation Configuration.” The next server type to talk about is the 
caching-only name server. 
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Figure 5.19 DNS console showing the secondary server zone information with the appropri- 
ate resource records. 


Installing a Caching-Only Name Server 


Caching-only name servers are DNS servers that provide two basic services: They handle 
queries and return the results to the client or resolver, and they cache returned queries 
for a specified time. Caching-only servers are not authoritative for any zones except for 
0.0.127.in-addr.arpa). In fact, caching-only servers never get registered because they have 
only bits and pieces of information. 


Caching-only servers can help reduce traffic in a network that is experiencing bandwidth prob- 
lems. For example, a small branch office that is part of a larger corporation has a slow Wide 
Area Network (WAN) connection to the corporate office. They use the corporate office to con- 
nect to the Internet and to resolve hostnames. The caching-only server can reduce network 
traffic across the WAN link by keeping a cache of recently resolved names. 


In this case, the caching-only server helps clients by the following: 


1. The client queries the caching-only name server on its network. 


2. The cache-only name server looks in the cache; if the entry is not in the cache, it queries 
the authoritative name server for the entry. 


3. The authoritative name server returns the query results to the cache-only server. 
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4, The result is placed in cache on the caching-only name server. 


5. The client receives the result from the cache-only server on its network. 


As you can see, the cache-only server can reduce network traffic over a WAN link by being 
able to locate information periodically in its own cache. In addition, because it does not main- 
tain any zone information, it does not have to replicate any information or provide resolution 
for any other name servers. 


An organization sees the benefits of the cache-only name server after the server has built up 
a reasonably large cache. As the number of queries that are handled by the cache-only name 
server increases, the cache grows and eventually reduces the amount of WAN traffic for reso- 
lution. 


To install a cache-only name server, simply install the DNS server service and don’t configure 
any forward lookup zones or reverse lookup zones. 


A cache-only name server performs better when it is configured to use forwarders, which allow 
it to perform recursive queries rather than iterative queries. A forwarder is a designated 
server that handles queries that the cache-only server cannot handle. This can greatly reduce 
network traffic across slow WANs because the cache-only name server sends only one packet 
across the WAN to the designated server, and it handles the resolution from there. When the 
resolution is complete, the result comes back across the WAN to the cache-only name server. 


To configure forwarders, open the DNS console, select the server, and then on the Action 
menu, click Properties. When the properties dialog box appears, select the Forwarders tab. On 
this tab, select the Enable Forwarders box and specify the IP addresses of all the DNS servers 
that you want to query (see Figure 5.20). You can also configure the period for which the serv- 
ice will wait for an answer before querying the next server in the list. The caching-only server 
queries all servers on the list until a successful result is returned. 


A quick reminder about the difference between an iterative query and a recursive query to 
keep us focused on why it is important about configuration parameters: 


W Iterative. This is the best answer that the server can provide. The DNS server will not 
query other name servers to attempt to find the answer. 

M@ Recursive. The request is made to a DNS server, and the DNS server seeks for the 
answer to provide absolute resolution. 


_ Most DNS servers default to iterative queries. However, for a cache-only server that is behind a slow WAN link, it is best to config- 
_. ure it for recursive lookups to reduce the amount of traffic across the WAN. 


Consider the use of cache-only servers on small networks that have to cross slow WAN links to 
resolve name queries. 
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Figure 5.20 Forwarders tab allows configuration of IP addresses of all DNS servers to be 
queried during name resolution. 


Installing an Active Directory-Integrated Name 


Server 


The long-awaited Active Directory for Microsoft has finally made its debut and moved 
Windows 2000 up into the enterprise level of network operating systems. To be successful, 
they will have to carry that over to Internet connectivity, which means DNS. With Active 
Directory—Integrated DNS name servers, you get the enterprise solution for effective resolu- 
tion. 


DNS is required for Active Directory because it is used as the locator service that resolves 
Active Directory domain, site, and service names to IP addresses. It also is involved in finding 
the logon service for a domain. You have the option to set up DNS as part of the process for 
installing Active Directory or as part of promoting the server to a domain controller using the 
dcpromo.exe command. 


If you currently have a DNS name server that is established on a Windows 2000 server that 
you want to incorporate Active Directory on, you can maintain the DNS server and change the 
zone type after Active Directory has been integrated. 
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| Active Directory installation is within the scope of this book, which assumes that the reader is familiar enough with Active 
a Directory to create the Active Directory-Integrated zones. 


To integrate DNS with Active Directory, you need to have Active Directory installed, or you 
can install and configure DNS as part of the Active Directory installation. DNS servers that 
are integrated into Active Directory have to be configured to run the DNS dynamic update 
protocol. 


The process of creating an Active Directory zone is to launch the DNS console and create a 
zone, making sure to select the Active Directory zone type instead of the standard primary or 
standard secondary. 


If you have an existing zone, you can follow these steps to change to an Active 
Directory—Integrated zone. Open the DNS console and select Action, Properties to get the 
properties box for your servers zone. On the General tab, you can select the Change button 
as shown in Figure 5.21. 
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((goelename 


awe 


Figure 5.21 You can change Primary Zone to Active Directory using the properties dialog 
box for your DNS server. 


This brings up the Change Zone Type window, which enables you to select an Active | 
Directory—Integrated zone type option. 
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At this point, you are warned, “Are you sure you want to convert to Active Directory— 
Integrated?” Select OK to go back to the properties page. Click Apply and notice that the type 
is now Active Directory—Integrated as shown in Figure 5.22. (You don’t even have to reboot; 
that alone is worth upgrading from Windows NT 4.0.) 
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Figure 5.22 Properties page showing Active Directory—Integrated zone. 


For Active Directory—Integrated zones, the data is stored as an Active Directory object and is 
replicated as part of the normal domain replication process. 


With the Active Directory—Integrated DNS zone, clients can dynamically update the DNS 
server. This is essentially taking the place of WINS in the Microsoft networking environment. 
The best news for the dynamic updates is that you can designate to allow only secure updates 
(see Figure 5.23). This means that only authorized clients have the ability to perform dynamic 
updates with the server. This is a nice security piece that many organizations will want to 
implement. The other advantage of Active Directory—Integrated DNS zones is that zone repli- 
cation can take place during Active Directory replication. 


Although this is an advantage, there is a potential downside to the zone replication taking 
place through Active Directory. The zones might be only loosely updated, meaning that in very 
large organizations there might never be completely replicated, 100-percent-complete zone 
information. However, the trade-off of performance for the security benefits far outweighs the 
possibility that you won’t have 100-percent-complete zones. 
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Figure 5.23 Active Directory—Integrated zone properties for dynamic updates. 


How do Active Directory—Integrated zones interact with non-Active Directory—Integrated 
zones? The Windows 2000 Active Directory DNS server plays well with other implementations 
of DNS that support the .SRV resource records. Preliminary tests indicate that the best way to 
get results with BIND servers is to use at least version 8.1.2 or later. To work with Windows 
NT 4.0 DNS servers, the NT 4.0 servers need to be running NT SP4 or later. SP4 made several 
changes to DNS in NT 4.0, the most significant being the addition of the .sRv resource record. 


This chapter has provided the basics for installing the different DNS name server types and 
some background on each one. The post-installation and additional configurations are covered 
in the next chapter. 


PoOsT-INSTALLATION 
CONFIGURATION 


The installation of the DNS server service is pretty straightforward and 
easy; the post-installation configuration parameters are a little more crucial 
to the proper implementation of DNS and will determine how effective the 
name resolution process is for your organization. 


This chapter will cover some of the post-installation configuration parame- 
ters that will provide a foundation for future growth, redesign, and perform- 
ance optimization. 
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General Configurations Options 


Many people, and very likely most readers of this book, have used, managed, or implemented 
DNS in Windows NT 4.0. I think we can all agree that configuration and management of a 
Windows NT 4.0 DNS server could be challenging at times and somewhat unpredictable most 
of the time (unless you configured DNS through text files). In this regard, Windows 2000 DNS 
has changed for the better. It is much easier to configure and maintain, and is much more pre- 
dictable. 


Most of the configuration can be done through the DNS console, which is found in the 
Administrative Tools menu. Through the console, you can do basic administrative functions 
such as 


Create and remove zones (forward lookup and reverse lookup zones) 
View properties of the server 

Remote administration 

Start, stop, pause, or resume the server 

Create and manage resource records 

Manage how zones are stored and replicated between servers 
Manage security for zones or resource records 

Configure how servers handle queries 

Configure how servers handle dynamic updates 


Manually update server data files 


Monitor and clear the DNS server cache 


These are several of the many functions that you have within the DNS console. One limitation 
within the Windows 2000 DNS console is the inability to manage any other implementation of 
DNS—it can only manage Windows 2000 DNS servers. Of course, as we completely migrate to 
Windows 2000, this will become less of a concern. 


Windows 2000 provides tools that allow management of DNS through command-line utilities. 
There are three basic utilities: 


nslookup—This diagnostic utility is used to display information, test configuration, and trou- 
bleshoot DNS. There are many commands that can be used with the nslookup command. This 
command is only available if TCP/IP has been installed. To test DNS server responsiveness, type 
the following command (at the command prompt): nslookup server_IP_address 127.0.0.1 
(server_IP_address is the address of the server). The response should return localhost. If you 
receive this response, then the server is responding correctly. There are many command-line 
features that are available with nslookup. To see a listing of all the commands, enter nslookup | 
at the command prompt and then help at the prompt that follows (as shown in Figure 6.1). 
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Figure 6.1 Typing help from the nslookup prompt reveals a listing of nslookup commands. 


The commands allow you to look for specific types of records and debugging information, and 
even create a text file that shows all of the records that are part of the zone (see Figures 6.2 
and 6.3). 
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Figure 6.2 nslookup can be used to create a text file of all records in a DNS zone. 
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Figure 6.3 In Windows 2000, the view dns command displays a file of DNS records. 


dnscmd—Command-line interface for administrating DNS servers. Some of the uses for this tool 
include scripting batch files, automating management, updating DNS server configurations, 
and setting up and configuring new DNS servers. This is a DOS lover’s paradise. The dnscmd 
can be installed in one of two ways: 


HM Copy the file from the distribution CD-ROM from the following path: 
\support \tools \support.cab 


=E Install the Windows 2000 resource kit, which can be found on the distribution CD-ROM 
in the following directory structure: \support\tools\2000rkst 


To learn about the commands available with dnsemd, go to a command prompt and type dnscmd 
/2. For complete details on all the commands and their usage, see the Windows 2000 resource 
kit Tools help. If you have installed the Windows 2000 resource kit, you can find the Tools 
Help under the Start menu by clicking Start, Programs, Windows 2000 Support Tools and 
Tools Help. 


ipconfig—This command is used to view and modify TCP/IP configurations. In Windows NT 
4.0, there were only a few commands available such as ipconfig, ipconfig /all, ipconfig 
/release, and ipconfig /renew. Windows 2000 provides many more command-line options with 
ipconfig, especially for DNS clients. Figure 6.4 shows the usage of ipconfig. Two of the neat 
commands are the /flushdns and registerdns commands. These commands work hand in hand 
with dynamic DNS and DHCP. This configuration will be talked about in more detail later on 
in this chapter. 
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Figure 6.4 The new and improved ipconfig in Windows 2000. 


Managing Resource Records 


After you have finished the preliminary configurations for the new DNS server(s), you will 
need to create and manage resource records. There are several types of resource records for 
DNS, and they all have their special meaning. We will discuss the most common resource 
records and list the remaining resource records that can be implemented. SOA and NS are the 
two most important resource records. Each of these will be covered individually later in this 
chapter. For now, we will list the records with a brief description. 


The most commonly used resource records are 


Host (A) resource records—Used to map domain computer names to IP v4 addresses (32-bit 
addresses). Host (A) records comprise most of the resource records in a zone. They are used 
primarily to identify computers that share resources. There are several ways that resource 
records can be added in Windows 2000: 


W Through the DNS console, you can manually add Host (A) resource records for hosts 
that have static IP addresses. 


E A qualified DHCP Server can update Host (A) resource records for DHCP-enabled clients 
of non-Windows 2000 Microsoft operating systems that obtain their IP addresses from 
the DHCP server. Currently, only Windows 2000 DHCP servers support this feature. 
Examples of the non-Windows 2000 DCHP clients would be Windows NT 4.0 and earlier, 
Windows 95/98, and Windows 3.x supporting DHCP clients. 


W Windows 2000 computers that are DHCP-enabled clients can dynamically register and 
update their own Host (A) resource records. This happens when they first obtain a 


DHCP lease, if there are changes to their IP address configuration, or when they release 
their DHCP lease. 
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RFC 1035 specifies resource records. The syntax for a Host (A) resource record is owner class 
ttl A IP_v4_address—for example, secondw2k.home.bobcollier.org IN A 10.0.0.50. 


Canonical name (CNAME) resource records—A\lso called alias resource records, map aliases or 
alternate domain names to the true domain names. These records allow the use of more than 
one name to point to a single host. The recommended uses of canonical resource records are 


M@ Renaming a host resource record within the zone—a canonical resource record can be 
used for temporary resolution to a new hostname. For example, we have a host called 
forest in the home. bobcollier.org zone. We want to rename the host to pelican, so we cre- 
ate a Host (A) resource record for pelican and then create a CNAME resource record for 
forest that points to the new Host (A) resource record of pelican. We can now get rid of 
the original Host (A) record of forest. The result of this is that users trying to resolve 
pelican, will be resolved to the new Host (A) record of pelican, users that try to resolve 
to forest will be resolved to the new Host (A) record of pelican. 


E Mapping a permanent alias name to a server that provides different services. The best 
example is a Web server that hosts www and ftp sites. To make resolution simple, you 
can do the following: Create the Host (A) resource record for the Web server; we will call 
it web. home.bobcollier.org, and map it to the appropriate IP address. Next, create a 
CNAME resource record called FTP and map it to web. home. bobcollier.org and create 
another CNAME resource record called www and map it to web. home. bobcollier.org. 
Now, both www and ftp will map to the single server called web. home. bobcollier.org. 


The syntax for the CNAME resource records is owner ttl class CNAME canonical_name—for 
example, ftp IN CNAME 1 testw2k.home.bobcollier.org. 


Mail Exchanger (MX) resource records—This resource record type is used to identify mail 
servers by email applications. When a piece of mail is sent through the Internet, it uses nor- 
mal hostname resolution just as any other transaction. If a piece of mail was addressed to 
collierr@home.bobcollier.org, the name is first resolved to home.bobcollier.org. If there is an 
MX resource record pointing to a server in the zone, the mail will be forwarded or exchanged 
to the appropriate mail server. If an organization has multiple mail servers, then you can pro- 
vide some redundancy, fault tolerance, and load balancing by mapping multiple servers with 
MX resource records; for example, the home.bobcollier.org zone has two Microsoft Exchange 
Servers (testw2k and secondw2k). We create an MX record type and point it to the parent 
domain home.bobcollier.org for testw2k and specify a preference value of 10. We create a sec- 
ond MX record type pointing to the parent domain home.bobcollier.org for secondw2k and 
specify a preference value of 20 (see Figures 6.5 and 6.6). 
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Figure 6.6 Mail exchanger (MX) resource record with a preference value of 20. 


The preference value allows for control on which server is the primary server for incoming 
Internet email. For load balancing, we could specify the same preference value for each server. 
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RFC 1035 provides in-depth information on MX resource records. The syntax for the MX 
resource record is owner ttl class MX preference mail_exchanger_host—for example, home. 
bobcollier.org IN MX 10 testw2k (where “10” is the preference value) and home.bobcollier.org 
IN MX 20 secondw2k (where “20” is the preference value). 


mitra 


_ Mapping to a Mail Exchanger Host 

a When mapping to the mail_exchanger_host, you can use either the simple hostname of the server or the FQDN of the server such 
: ' as testw2k or testw2k.home.bobcollier.org. Either of these will work. By using just the hostname, it is assumed that you are using 
_| the parent domain. 


Pointer (PTR) resource records—These records are primarily used to support the reverse 
lookup process. After you have created a reverse lookup zone for your site, PTR records allow 
users to resolve IP addresses to hostnames or Fully Qualified Domain Names (FQDN). In 
Windows 2000, there are several ways that PTR resource records can be added to a zone: 


E Manually—If you have hosts or servers that have static IP addresses, then you can man- 
ually add the PTR resource records using the DNS console. 


HM Semiautomatic—When manually adding Host (A) resource records, you can automatically 
have the PTR resource record added. To add the PTR record using this method, simply 
check the box next to Create Associated Pointer (PTR) Record as shown in Figure 6.7. 


| Tinetoive TTL: 
p 100 


Figure 6.7 Pointer (PTR) record check box used to add a PTR record. 


E DHCP Registration—A qualified DHCP Server can register or update PTR resource 
records for DHCP-enabled clients of non-Windows 2000 Microsoft operating systems that 
obtain their IP address from the DHCP server. Currently, only Windows 2000 DHCP 
servers support this feature. Examples of the non-Windows 2000 DCHP clients would be 
Windows NT 4.0 and earlier, Windows 95/98, and Windows 3.x supporting DHCP clients. 

@ Auto Client Registration—Windows 2000 computers that are DHCP-enabled clients can 
dynamically register and update PTR resource records. This happens when they first 


obtain a DHCP lease, if there are changes to their IP address configuration, or when 
they release their DHCP lease. 
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RFC 1035 describes pointer (PTR) resource records in more detail. The syntax for PTR 
resource records is as follows: owner ttl class PTR primary_domain_name—for example, 
1.0.@.1@.inaddr.arpa. PTR forest.home.bobcollier.org 


Service location (SRV) resource records—When using Active Directory to located domain con- 
trollers in Windows 2000, service location (SRV) resource records are required. This allows the 
use of several servers in a single-domain environment while remaining able to move servers 
around to different locations, all while remaining transparent to users. An administrator 

also can designate certain target hosts as primary servers for a particular service. There are 
several SRV records that are automatically created during the installation of Active Directory, 
as seen in Figure 6.8. | 
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Figure 6.8 The service location (SRV) records automatically created in Windows 2000 DNS. 


The main SRV records that are created are for ldap, Kerberos, Global Catalog, and domain 
controllers services (refer to Figure 6.8). These resource records allow multiple servers that are 
providing similar services to be located with a single query to a DNS server. There are several 
fields of an SRV record: 


E Name, or domain—This defines the domain name referred to by this resource record. 


Æ Service—This is a name for the service. For well-known services, there are reserved uni- 
versal symbolic names. RFC 1700 defines each of these well-known services along with 
their symbolic names. 


E Protocol—This is the transport protocol that the service uses—for example, TCP or UDP. 
Protocols are defined in RFC 1700. 
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© Priority—This is the preference value, similar to that of an MX resource record, defining 
which server resource will be accessed first. This sets the priority of how services will be 
accessed throughout the network. Target hosts that have SRV records with lower values 
will be accessed more frequently than target hosts with higher SRV values. The values 
range from 0 to 65,535. For target hosts with the same SRV values, they will be accessed 
in random order. The default value is “0”. 


E Weight—This is an additional mechanism that can be used to provide load balancing 
between multiple servers offering the same services. If multiple servers have the same pri- 
ority value, the weight can be configured to make the selection process a bit more definitive. 
For example, I have two servers (testw2k and secondw2k) that offer the _ldap directory 
service. Both SRV records have a priority of “0”. If I want users to access secondw2k for 
_ldap services more often than testw2k, then I would place a value of 1 in the weight field 
on secondw2k and a weight value of 10 on testw2k. This would allow the majority of 
requests to filter through the secondw2k server. For load balancing, the values range from 
1-65,535. If no load balancing is required, it is best to use a value of “0”. The default value 
is “100”. 

mM Port number—This is also referred to as port and specifies the entry point for the service on 
the target host. There are well-known ports that should be routinely used, as defined in 
RFC 1700. However, any unassigned ports can be used ranging between 0 and 65,535. 


E Host offering the service—This is referred to as target host and specifies the DNS host that 
is providing the service. This field indicates the DNS hostname for the host and has to have 
a corresponding Host (A) resource record. A “.” can be used to indicate authoritatively that 
the requested service is not available at this DNS namespace. More information about SRV 
resource records can be found in the Internet-Draft “A DNS RR for specifying the location 
of services (DNS SRV).” The syntax for an SRV resource record is service.protocol.name ttl 
class SRV preference weight port target. For example, ldap.tcp.home.bobcollier.org SRV 0 
100 389 secondw2k.home.bobcollier.org, as seen in Figure 6.9. 


_Idap Properties T i 2) x} 


Service Location (SRV) | Security | 


Domain: [home bobcoller.org 


Host offering this service: 
fsecondw2k. hore, bobcollier. org. 


IV Delete this record when t becomes stale 
Record time stamp: 11/26/1993 12:00:60 PM 


Time to live {TTL}: fp 0 :10 0 


Figure 6.9 Properties for the _ldap Resource Record. 
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SRV resource records will play an important role in Windows 2000 and should be planned 
carefully. As we have mentioned before, planning, planning, planning will be the key to a suc- 
cessful deployment of Windows 2000. 


The Hints File 


The hints file contains local information stored on a DNS server that provides specific resource 
records to direct the server to its root servers. For DNS, the root hints are stored in the file 
cache.dns, located in the \%Systemroot%\System32\Dns folder. 


Hints files are used to allow authoritative servers of nonroot zones to discover or learn which 
authoritative servers manage domains at higher levels and in other DNS domain namespaces. 
Hints files are used heavily in recursive lookups. For recursive lookups to be performed prop- 
erly, there needs to be contact information containing the addresses to root-level servers. 
These servers can either be internal to your DNS domain namespace or they can be pointed to 


the Internet Root Servers. 


By default, if you install the DNS server service on a server, a cache. dns file is created in 
\%Systemroot%\System32\Dns folder. This file is what contains the Root Hints information. 
If the DNS server is not a root server, the cache.dns file is a standard file of all root servers for 
the Internet. The file contains some of the following information: 


A.ROOT-SERVERS.NET. 
B.ROOT-SERVERS.NET. 
C.ROOT-SERVERS.NET. 
D.ROOT-SERVERS.NET. 
E.ROOT-SERVERS.NET. 
F.ROOT-SERVERS.NET. 
G.ROOT-SERVERS.NET. 
H.ROOT-SERVERS.NET. 
I.ROOT-SERVERS.NET. 
J.ROOT-SERVERS.NET. 
K.ROOT-SERVERS.NET. 
L.ROOT-SERVERS.NET. 
M.ROOT-SERVERS.NET. 


360000 NS 
360000 NS 
360000 NS 
360000 NS 
360000 NS 
360000 NS 
360000 NS 
.30000 NS 
360000 NS 
360000 NS 
360000 NS 
360000 NS 
360000 NS 


198.41.0.4 
128.9.0.107 
192.33.4.12 
128.0.10.90 
192.203.230.10 
192.5.5.241 
192.112.36.4 
128.63.2.53 
192.36.148.17 
192.41.0.10 
193.0.14.129 
198.32.64.12 
202.12.27.33 


This is an excerpt from the cache.dns file that is stored locally on the DNS server. If you do not 
have this file, it can be downloaded from the following URL: 
ftp://ftp.rs.internic.net/domain/named.cache. As an administrator, you should periodically 
check this Web site for changes to the file. As the Internet grows, this file will change on a reg- 


ular basis. 
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If you are interested in finding the IP addresses to all of the top-level DNS servers in the 
world, you can obtain this information from InterNIC as well. The following table gives the 
appropriate URLs for the main top-level domains: 


Table 6.1 Top-Level Domain URL Listing 


Top-Level Domain URL 

ARPA ftp://ftp.rs.internic.net/domain/arpa.zone 
All root servers ftp://ftp.rs.internic.net/domain/root.zone 
EDU ftp://ftp.rs.internic.net/domain/edu.zone 
GOV ftp://ftp.rs.internic.net/domain/gov. zone 


For each of these top-level domains, there are hundreds of servers located throughout the 
world. 


If your DNS server is being configured to only host your internal network, then you should 
modify the root hints on each of your servers so they point to other servers in your organiza- 
tion. To modify the root hints on your DNS server, open the DNS console and select the speci- 
fied server. On the Action menu, click Properties. Select the root hints tab. To add a root 
server to the list, click the Add button and provide the DNS namespace for the server and the 
IP address. If you want to modify a root server entry, then you would select the Edit button in 
the Root Hints tab. To remove a root server, select Remove button. See Figure 6.10 for the 
Root Hints properties tab. 


Figure 6.10 Root servers can be added, modified, or removed through the Root Hints proper- 
ties tab. 
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As stated earlier, the Root Hints are important in being able to properly perform recursive 
lookups. Here is an example of how this process works: 


Let’s say that you want to find ftp.microsoft.com and you are a host that is configured to use 
10.0.0.10 as your primary DNS server. The initial request for the site ftp.microsoft.com gets 
forwarded to your DNS server (10.0.0.10), and the server will look for a reference for 
ftp.microsoft.com in its database. If the entry is not located there, it goes to the root hints 
(cache.dns) and looks up the root servers. It passes the query to the root server requesting 
information for com servers. This information is passed back to the originating DNS server 
(10.0.0.10). Next, the query is passed to a com server requesting information about the 
microsoft.com zone. The result is passed backed to the 10.0.0.10 DNS server. With the new 
information, the query is now passed to the microsoft.com server requesting the IP address to 
ftp.microsoft.com. After the results are sent back to the originating DNS server, the informa- 
tion is stored in cache for a specified period of time, and the query results are passed on to the 
client (resolver) who requested the information. Now, the client makes a direct connection with 
ftp.microsoft.com. 


This is how the recursive process works. Without the root hints file, the DNS server would not 
have been able to resolve the name for the client. 


Deleting cache. dns File 

When configuring a server as an internal root server, it is recommended that you delete the cache. dns file completely off of 
your DNS server. The Root Hints will only cause more overhead on your DNS server, as it tries to connect to each of the root 
-servers on the Internet. 


The “.” Zone 


This is referred to as the root zone. When you implement Active Directory and configure your 
DNS server, you have a couple of options as to how you will configure the root zone. If you will 
be connected to the Internet, the root zone is configured as “.” with the following default 
entries: “arpa” with sublistings of in-addr and 10 and “org” with subentries of bobcollier and 
home, as shown in Figure 6.11. 


| Identification of DNS Namespace and IP Address 
| | Your defaults will be determined by your Active Directory DNS namespace and your IP address. The example described here is 
_. using my Active Directory namespace. 


The root of the forest, which is a domain controller, has the “.” directory listing and is used as 
the authoritative DNS server for the entire organization. When using an FQDN that is regis- 
tered on the Internet, this server handles queries coming into your organization, just as we 
described in the previous section. The “.” directory is typically only on the top-level DNS server 
(root server). | 
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Figure 6.11 A sample Root “.” forward lookup zone on a DNS server in the root of the forest. 


What happens if you are not connected to the Internet? Microsoft has reserved a top-level root 
designation called local. If you install a root server and choose not to be connected to the 
Internet, then the DNS root will be .local. This reserved root serves the same purpose as the 
normal “.” and provides the same functionality, except it only works for the intranet. In fact, 
this DNS namespace cannot be registered on the Internet. To convert this root from a local to 
an Internet root, your organization would have to uninstall Active Directory and DNS and 
reinstall with the organizations registered FQDN. Plan this very carefully, making sure that 


you look ahead to future possibilities. 
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If you do not have a “.” zone and need to create one, you can simply create a forward lookup 
zone and name it “.” (G houl the quotes), and then specify all the information. 


After you have this configured, the process is pretty much on autopilot and transparent to 
users. 


Configuring DNS Notify 


DNS notify is a specification that defines how master servers update slave or secondary 
servers. RFC 1996 provides this specification and can be found at the following URL: 
ftp://ftp.rs.internic.net. 


DNS notify is only required when you have primary and secondary name servers. If you have 
implemented Active Directory—integrated zones, then you will not need to configure DNS 

notify. Active Directory—integrated zones query the Active Directory roughly every 15 minutes 
and pull changes to the namespace. For this reason, it would be impractical to configure DNS 
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notify because of the additional traffic requests for updating zone information and can actually 
degrade system performance. 


_ Zone Transfers 
_ For the purpose of this section, we will assume that the zone transfers are happening between primary zones and secondary 
| zones. 


Windows 2000 DNS supports the use of DNS notify, which implements a push mechanism of 
initiating notification to slave or secondary servers when zone changes occur. After servers are 
notified, they initiate a zone transfer to pull zone information and make changes to their local 
replicas of the zone. Zone transfers can either be full zone transfer (AXFR) or an incremental 
zone transfer (IXFR). The AXFR transfers the entire zone database each time there is a 
change to the zone. With the IXFR, only the changes to the zone are replicated. RFC 1995 
describes the incremental zone transfer. 


DNS Notify—The Process 


The DNS notify process is fairly straightforward. Whenever zone changes occur at the master 
server, the serial number field in the SOA resource record is updated, or incremented by one, 
which indicates that there is a new version of the zone. The master server then sends or 
pushes a DNS notify message to the slave servers that are on its notify list. All slave servers 
that receive the notify message can then initiate a zone transfer request to pull the new infor- 
mation. 


That was the simplified version—now let’s take a closer look at some of the behind-the-scenes 
mechanisms that occur. The DNS notify uses portions of the DNS message format. Any field 
that is not specified should contain a binary zero (0) value. DNS notify uses a nonguaranteed 
transport protocol (UDP) unless one of the following situations is present: 


WE The data is too large to fit in a UDP/DNS datagram. 


ŒE There is a firewall between the master server and slave servers and TCP is the only 
allowed port configured. 


-| Transport Mechanisms of TCP/IP 

Remember that TCP/IP has two transport mechanisms—TCP or UDP Transmission Control Protocol (TCP) is connection-oriented, 
guaranteed delivery and designed for larger packets. The User Datagram Protocol (UDP) is connectionless, nonguaranteed, best 
effort, and is designed for smaller packets. — 


In the event that a notify request is not responded to from a slave server, the master server 
will periodically send another notify message until too many copies have been sent, an Internet 
Control Message Protocol (CMP) is returned indicating that the port is unreachable, or the master 
receives a response from the slave server. 
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Once the slave server receives the notify message and sends a response, it can now initiate a request for 
zone transfer. During the zone transfer, the slave server will defer actions on any subsequent notify 
messages until the original transaction is complete. This prevents the master server from becoming 
overwhelmed with additional zone transfer requests. 


The NOTIFY message has the following characteristics: 


query ID: (new, incremented from previous version) 
op: NOTIFY (4) 

resp: NOERROR 

flags: AA 

qcount: 1 

qname: (appropriate zone name) 

qclass: (appropriate zone class) 

qtype: T_SOA 


The NOTIFY response has the following characteristics: 


query ID: (same as NOTIFY message) 
op: NOTIFY (4) 

resp: NOERROR 

flags: QR AA 

qcount: 1 

qname: (appropriate zone name) 
qclass: (appropriate zone class) 
qtype: T_SOA 


Notice the query ID is the same as the NOTIFY request (message); this has to be the same so the mas- 
ter server knows the transaction was successful. Also notice the flags has the QR bit set as well—this 
indicates that this is a response. 
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Configuring the Notify List 


To create and manage a notify list for a zone, open the DNS console and select the appropriate zone. 
On the Action menu, click Properties. Select the Zone Transfers tab and click Notify and check the 
Automatically Notify check box. You have two options to use: 


W The Following Servers—This allows you to specify which servers to be included in the 
notify list, which are different from the list in the Name Servers tab. To add a server, 
type the IP address of the server(s) to be notified and click the Add button. To remove a 
server to be notified, select the IP address to the corresponding server and click the 
Remove button (see Figure 6.12). 
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Figure 6.12 The following servers option can be used to specify which servers are included on the 
notify list. 


M@ Servers Listed on the Name Servers Tab—This is the default configuration. This 
allows only the servers that are shown in the Name Servers tab of the zone proper- 
ties dialog box, as shown in Figure 6.13. 


While this covers the DNS NOTIFY process, it is important to remember not to configure DNS 
NOTIFY if you are using Active Directory—integrated zones. 
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Figure 6.13 Name Servers property box. 


Configuring Start of Authority (SOA) Resource 
Records 


The primary concept of zones is based on server authority. When a zone is loaded, it uses two types of 
resource records to determine the authoritative properties of the zone: the Start of Authority (SOA) 
resource record and the Name Server (NS) resource record. We will focus on the SOA resource record 
during this section of the chapter and will visit the NS resource record during the next section. 


The SOA resource record is always the first in any standard zone, because it defines the DNS server that 
either originally created it or is now the primary server for the zone. The SOA resource record is auto- 
matically added by the Add New Zone Wizard whenever a new primary zone is created using the DNS 
console. The SOA resource record stores several properties that define how zone renewals and 
expirations will be done, and how often zone transfers will occur between authoritative servers 
for the zone. Each SOA resource record contains the following information (see Figure 6.14). 


Æ Serial Number—Displays the number used to determine if a zone transfer is needed to 
update the zone (referred to as the revision number). Each time the zone changes, this 
number is increased by a value of 1 to indicate a new version. This number is checked 
and compared by servers during zone refresh requests to determine if a zone has 
changed and if a transfer is needed to update it. You can use the Increment button to 
increase this number manually, forcing a zone transfer to occur. It is important that this 
number be incremented by at least one whenever a zone change occurs, so that zone 


transfers can take place. The zone transfers will either be incremental zone transfers 
(IXFR) or full zone transfers (AXFR). 
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Figure 6.14 The Start of Authority configuration box shows details about the SOA resource 
record. 


M@ Primary Server—This is the host or FQDN name for the primary master DNS server for 
the zone. You have the option of typing the hostname for the primary master DNS 
server or you can click the Browse button to search the directory. If there is no hostname 
provided or an incorrect hostname is provided, then zone transfers will never take place. 


M Responsible Person—This field contains the email address of the person who is responsi- 
ble for managing this zone. The mail address is in a standard DNS FQDN format. For 
this field a “.” is used to replace the “@” in the email address. Without this field correctly 
filled in, there is no means to contact anybody in the event of a failure of the SOA 
resource record or problems within the zone. 


M@ Refresh Interval—The time that a secondary name server will wait before querying the 
primary master to renew its zone information. After the refresh interval has expired, the 
secondary server contacts the primary master server to request the SOA of the primary 
master server. After the SOA has been retried, the secondary name server compares the 
serial number of the SOA from the primary master to its own SOA resource record. If 
the serial numbers are different, then a zone transfer is requested by the secondary 
name server. The default value is 900 seconds (or 15 minutes). 


WE Retry Interval—Time interval that indicates how often a server that hosts a secondary of 
this zone continues to retry transfer of the zone. Specifically, this number is used when 
the server fails to contact its configured master DNS server (source) for the zone after 
the Refresh interval has expired. The default time is 600 seconds, or 10 minutes. 
Generally, this interval is shorter than the Refresh interval. 


M@ Expires After—Referred to as Expire interval, used to specify a time period that DNS 
servers hosting secondary copies of this zone use to determine when zone data should be 
expired if it has not been verified to be current and refreshed from its source server. If 
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zone data expires, secondary server considers its data to be inaccurate and will no 
longer respond to queries after the failure to renew or update the zone information. 
The default time for this value is 86,400 seconds, 1,440 minutes, or 24 hours. 


@ TTL for This Record—Also referred to as the minimum (default), TTL is a value applied 
to all resource records without an individually specified TTL. The TTL is used by other 
DNS name servers and some DNS clients to determine how long they are allowed to 
cache information, returned from DNS, about this record. The format of the time typed 
should be in days (DDDDDD), hours (HH), minutes (MM), and seconds (SS). The default 
value is 3,600 seconds, 60 minutes, or 1 hour. Any record that has an individual TTL 
value specified overrides the default TTL value specified in the SOA. 


The following is an example of a default SOA resource record: 


@ IN SOA testw2k.home.bobcollier.org. administrator.home.bobcollier.org. ( 


3 ; serial number 
900 ; refresh 

600 ; retry 

86400 ; expire 


) ; Minimum TTL 


Figure 6.15 shows an nslookup query for SOA. 


Figure 6.15 An nslookup query of an SOA resource record. 


Without the SOA resource records, DNS cannot functionally update all the servers within its 
zone of authority, which would render the DNS query process useless or, at best, burdensome. 
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Adding NS Resource Records 


The second record of great importance is the Name Server (NS) resource record. This is the 
second resource record that is loaded when a DNS server is initialized. The NS resource record 
is used to assign authority for a DNS domain namespace by establishing a list of authoritative 
servers for the domain and by indicating the authoritative DNS servers for any subdomains 
delegated away from the zone. 


Generally, secondary servers have authoritative control for a zone and the IP addresses to 
those servers will be included in the primary server’s NS resource record (refer to Figure 6.12 
to see the Name Servers tab again). The end result of this is that the secondary servers are 
advertised as being authoritative for a zone and will receive some of the queries to provide 
load balancing and redundancy. Each server that is part of the NS record should also have a 
Host (A) resource record identified within the zone. 


The Host (A) resource record entry becomes a little more important in the event of zone dele- 
gation to a subdomain, because the resource record usually contains out-of-zone names. 


When delegating zones within your namespace, you will need delegation-of-authority resource 
records in other zones that point to the authoritative DNS servers for the new zone. These out- 
of-zone NS and A resource records are called glue records. 


To specify other DNS servers as authoritative for a zone, open the DNS console and select the 
appropriate DNS server and zone. On the Action menu, click Properties, and then the Name 
Servers tab. Click Add, specify the IP address, and click the add Button. That finishes the con- 
figuration of the NS resource record. The benefits of having more than one authoritative 
server are 


M Provides zone redundancy 
WŒ Can reduce network traffic, especially across a slow WAN link 
M Provides load balancing by reducing the demands on the primary DNS server for a zone 


The syntax for an NS resource record is owner ttl IN NS name_server_domain_name—for exam- 
ple, home.bobcollier.org. IN NS testw2k.home.bobcollier.org. 


Configuring Dynamic Zone Update 


Dynamic updates are a real nice addition to Microsofts DNS because they allow client comput- 
ers to register and dynamically update their resource records with a DNS server whenever 
changes occur. RFC 2136 defines dynamic updates in the Domain Name System (DNS 
Update). 


First, a little history of the implementation of DNS. Originally, DNS was designed to support 
queries to a statically configured database. In the beginning, this was not a big problem 
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because there were not so many changes; however, as the Internet became the Internet of the 
90s, the frequency of changes was almost nonstop. Simply said, the community has outgrown 
statically configured DNS servers. Hence, the advent of dynamic DNS. 


The DNS dynamic update protocol allows updates directly from clients or from a DHCP server 
on behalf of the client. Windows 2000 computers dynamically update their Host (A) resource 
record and pointer (PTR) resource record if they are configured to use TCP/I[P—even clients 
that are configured with a static IP address. When registering with DNS, Windows 2000 com- 
puters will register their FQDN, which is composed of the computer name and the primary 
DNS suffix. Dynamic updates can be sent for any of the following reasons or events: 


E Any change to the configuration of a computer’s TCP/IP properties to include adding an 
IP address, removing an IP address, or modifying the IP address information 


Œ Ifthe IP address lease is renewed or changes 
E Ifthe ipconfig/registerdns command is used 


HM Whenever the computer is turned on and successfully initializes TCP/IP with a valid 
network address 


The mechanism or service that handles dynamic updates is the DHCP client service, not the 
DNS client service. This section will focus on clients that have statically assigned IP addresses 
and how they update the A resource record with the DNS server using dynamic updates. 


For clients that are statically configured, dynamic updates are generally configured when an 
IP address changes or the DNS name changes on the computer. Let’s use an example of chang- 
ing the DNS name for a host that was called host1.home.bobcollier.org to host25.home. 
bobcollier.org. After this name is changed and applied, the computer will need to be restarted. 
As the client computer begins to initialize, the DHCP client service performs the following 
actions: 


E The DHCP client service sends an SOA-type query using host25.home.bobcollier.org. 


=E The authoritative DNS server for the zone responds to the SOA-type query. For the 
standard primary zones, the response returned is fixed and static, meaning that it 
always matches exactly as it appears in the SOA resource record. If the zone is Active 
Directory—integrated, any DNS server can respond and dynamically insert its own name 
as the primary server of the zone. 


E The DHCP client service attempts to contact the primary DNS server. Once contact is 
made, the DHCP client service sends a dynamic update request to the primary server. If 
the update succeeds, the transaction is complete. If, however, the update fails, the client 
next sends an NS-type query for the zone specified in the SOA query response. Once the 
response of the NS-type query is received, the client attempts contact of the first server 
on the list and sends another SOA-type query and will attempt contact of the primary 
server to submit the dynamic update. If this fails, the client will attempt contact of the 
next primary server in the list and will continue to do so until a successful update has 
been accomplished. 
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Periodically, information will be refreshed or updated with the primary name server, by 
default every 24 hours. If there are no changes, then the zone retains its current version. DNS 
does not remove names if they are not refreshed or updated every 24 hours. 


CONFIGURING DNS 
CLIENTS 


Traditionally, the Domain Name System (DNS) was designed to handle 
queries of a statically configured database. Information was expected to 
change periodically but the frequency of changes was expected to be fairly 
low. When authoritative information needed to be changed, a network 
administrator would have to manually modify the zone file that contained 
the information that needed to be changed. 


With the advent of Dynamic Host Configuration Protocol (DHCP) automat- 
ing TCP/IP addressing, the “standard” method of updating DNS became 
impractical. It became extraordinarily difficult to manage all of the frequent 
updates. It became obvious that DNS needed to be dynamically updated by 
clients and DHCP servers. The Dynamic Update Protocol was introduced 
and is defined in RFC 2136. 


This chapter describes how various clients’ information can be automati- 
cally updated in the Windows 2000 DNS server. The updates can be config- 
ured in different ways, depending on the type of clients that are on the 
network. We will look at the following client scenarios: 


W Windows 2000 clients 

mM Windows 9.x clients 

mM Windows NT 4.0 clients 

E Non-Active Directory—aware clients 
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Windows 2000 Clients 


Registration of host (A) and pointer (PTR) resource records is attempted by each Windows 
2000 computer via the DHCP client. The DHCP client service runs on every machine regard- 
less of whether it is configured as a DHCP client or not. Figure 7.1 shows the DHCP client 
service started on Windows 2000 Advanced Server, configured as a Domain Controller and a 
DNS server. Notice the DHCP client service is configured as automatic and is started. The 
DHCP client service is responsible for the dynamic updates to the DNS server. 
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Figure 7.1 A Windows 2000 Domain Controller configured with the DNS service, with 
DHCP client running. 


First, we will review the TCP/IP configuration of a Windows 2000 client and talk about differ- 
ent configurations for the client. To look at the properties of TCP/IP on a Windows 2000 client: 


1. Select Start, Settings, Network and Dial-up Connections 

2. In the Network and Dial-up Connections dialog box, highlight Local Area Connection. 
3. On the File menu, select Properties. 

4, When the Local Area Connections Properties dialog box appears, highlight Internet 


Protocol (TCP/IP) and select the Properties button. This presents the Internet Protocol 
(TCP/IP) dialog box. 


This is the general configuration page that allows you to determine whether the client is to be 
configured as a DHCP client or statically configured. This property page also allows the option 
of either Obtain DNS Server Address Automatically or to Use the Following DNS Server 
Addresses. You have the option of supplying two TCP/IP address. If you are using a DHCP 
server and have configured a scope, you should select the Obtain DNS Server Address 
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Automatically. If you are statically configuring a client, you should select Use the Following 
DNS Server Addresses and input the appropriate TCP/IP addresses. 


For the dynamic updates to DNS to occur, you will need to select the Advanced button in the 
Internet Protocol (TCP/IP) dialog box and then select the DNS tab (shown in Figure 7.2). 
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Figure 7.2 This figure shows the Advanced TCP/IP Settings dialog box, DNS tab for a 
Windows 2000 TCP/IP client. 


Clicking the DNS tab brings up the Advanced TCP/IP settings dialog box. In this box, there 
are a few configuration parameters: 


E DNS Server Addresses, in Order of User—This option lists the TCP/IP addresses of 
DNS servers that the Windows 2000 client will query to resolve DNS domain names 
used on this computer. DNS servers are queried in the order in which they are listed 
here. 


E Append Primary and Connection Specific DNS Suffixes—This option specifies 
that resolution for unqualified names that are used on this computer are limited to the 
domain suffixes of the primary suffix and all connection-specific suffixes. For example, if 
the primary DNS suffix is pelicancreek.home.bobcollier.org and you ping mustang, then 
Windows 2000 queries for mustang.pelicancreek.home.bobcollier.org. 


E Append Parent Suffixes of the Primary DNS Suffix—tThis option specifies whether 
resolution for unqualified names used on this computer includes parent suffixes of the 
primary DNS suffix all the way up to the second-level domain. For example, if the pri- 
mary DNS suffix is pelicancreek.home.bobcollier.org and you ping mustang, then 
Windows 2000 queries: 
mustang.pelicancreek.home .bobcollier.org and 
mustang.home.bobcollier.org and 


mustang.bobcollier.org 
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Append These DNS Suffixes (in Order)—This option specifies that resolution for 
unqualified names used on this computer are limited to the domain suffixes listed in 
this box. The primary DNS suffixes are not used for resolution of unqualified names. 
For example, if pelicancreek.home.bobcollier.org and testw2k.home.bobcollier.org were 
added to the Append These DNS Suffixes (in Order) list box, then pinging mustang 
would result in Windows 2000 querying the following: 


Mustang.pelicancreek.home.bobcollier.org and 
Mustang.testw2k.home.bobcollier.org 


DNS Suffix for This Connection—This option allows you to specify a DNS suffix for 
this connection. If this connection is configured by a DHCP server and this option is left 
blank, then the DHCP server assigns the appropriate DNS suffix. If you specify the DNS 
suffix, then the information from the DHCP server will be ignored. An example of a DNS 
suffix is home. bobcollier.org. 


Register This Connection’s Addresses in DNS—tThis option specifies that the client 
will attempt to register its TCP/IP addresses to the DNS server dynamically. This elimi- 
nates the need for having to manually update the DNS zone when clients’ TCP/IP 
addresses change. 

Use This Connection’s DNS Suffix in DNS Registration—This option specifies 
whether the dynamic DNS update is used to register both the TCP/IP addresses and the 
connection-specific DNS name for this connection. For example, if your primary DNS 
suffix is pelicancreek.home.bobcollier.org and you also have specified a connection- 
specific DNS suffix of home.bobcollier.org, then the client would attempt to dynamically 
register its TCP/IP addresses to the following zones: 

Pelicancreek.home.bobcollier.org and 

Home. bobcollier.org 


The end result of this configuration allows a user to successfully ping mustang or 
mustang.pelicancreek.bobcollier.org or mustang.home.bobcollier.org 


These are the configuration properties that are available for TCP/IP and the dynamic DNS 
update. For the client to dynamically register with DNS, the Register This Connection’s 
Addresses in DNS must be selected. For the remainder of this chapter, we are assuming that 
the Windows 2000 client is configured to dynamically update DNS. 


The dynamic update protocol uses an algorithm to make updates to the DNS server. The algo- 
rithm is described in RFC 2136. The dynamic update algorithm differs depending on the type 
of client access and adapter type. We will look at four scenarios: 


Windows 2000 DHCP client 

Windows 2000 client configured with static TCP/IP address 
RAS client 

Windows 2000 secure dynamic updates 
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Windows 2000 DHCP Client 


When a Windows 2000 client is configured as a DHCP client, the DHCP client service boot- 
straps to the DHCP server and negotiates the dynamic update procedure with the DHCP 
server. The default and preferred setting is to have the client update the host (A) resource 
record and the DHCP server update the pointer (PTR) resource record. The significance of this 
configuration is as follows: 


E The client is tagged as the owner of the host (A) resource record and is the only one that 
can make changes in DNS. 


E The DHCP server is tagged as the owner of the pointer (PTR) resource record and is the 
only one that can make changes in DNS. 


E The client is responsible for updating and removing the host (A) resource record. The 
DHCP server cannot make changes or remove the resource record. 


mM The DHCP server is responsible for updating and removing the pointer (PTR) resource 
record. The client will not remove the resource record from DNS. 


The DHCP server can be configured to Update DNS Only If DHCP Client Requests or Always 
Update DNS. Figure 7.3 shows the DNS configuration tab of the DHCP server properties. You 
can get to this screen by selecting Start, Programs, Administrative Tools, DHCP. This will 
open the DHCP management console. To find the DNS tab properties, select the DHCP server 
you want to configure, and select Action menu, Properties. This will show the DHCP server 
properties page. The DHCP client service is responsible for the dynamic updates to the DNS 
server. Click the DNS tab. 


workhorse.pelicancreek.home.bobcolber.org [192 1660.1107 
General DNS | Advanced | 


You can set up the DHCP server to automatically update name and address 
information on DNS servers that support dynamic updates. 
I Automatically update DHCP client information in DNS 

@ Update DNS only f DHCP client requests 

C Always update DNS 
Discard forward {name-to-address} lookups when lease expres 


T~ Enable updates for DNS clients that do not support dynamic update 
Updates are sent to DNS servers configured in TCP/IP properties for 
network connections active at this server. 


cen en s] 


Figure 7.3 This is the configuration dialog box for how the DHCP server will handle DNS 
updates. 
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There are five options to consider when configuring the DHCP server to dynamically update 
the DNS server. These options are 


=E Automatically Update DHCP Client Information in DNS—This specifies whether 
the DHCP server sends DNS dynamic record updates to the DNS server. Updates are 
sent to DNS servers configured in TCP/IP client properties for any active network con- 
nections at the DHCP server. (This is the default configuration.) 


=E Update DNS Only If DHCP Client Requests—tThis specifies that the DHCP 
server updates forward and reverse lookups, which are based upon the type of 
request made by the client during the lease process. (This is the default configu- 
ration.) | 


@ Always Update DNS—This specifies that the DHCP server always updates for- 
ward and reverse DNS lookups when a client acquires a lease, regardless of the 
DHCP client’s request. 


@ Discard Forward (Name-to-Address) Lookups When Lease Expires—This speci- 
fies whether the DHCP server discards forward DNS lookups for clients when a lease 
expires. (This is checked by default to allow the DHCP server to remove the host (A) 
resource record from DNS when the client DHCP lease expires.) 


E Enable Updates for DNS Clients That Do Not Support Dynamic Update—this 
specifies whether the DHCP server sends dynamic updates to the DNS server for any 
DHCP clients that do not directly support performing these updates. If selected, clients 
running under earlier versions of Windows are updated by the DHCP server for both 
their host (A) and pointer (PTR) resource records. (This is not selected by default; ifin a 
mixed environment, you might consider checking this option to have dynamic updates of 
earlier clients.) 


There are some ramifications of the choices you make here that were briefly mentioned earlier. 
Letting the client update the DNS server with both the host (A) and pointer (PTR) resource 
records makes the client the owner of both resource records. This is the scenario when the 
DHCP server is not configured to Automatically Update DHCP Client Requests as shown in 
Figure 7.4. 


We will look at two scenarios involving clients’ registrations with DNS. The first scenario 
involves the client doing a controlled shutdown. The second scenario will involve a client per- 
forming a release and renewal of the TCP/IP address. (This is what happens when a client’s 
lease expires, or they obtain and renew a TCP/IP address.) 


a The term controlled shutdown refers to shutting the machine down gracefully. That is, by selecting Start, Shut Down, Shut down, 
. and then clicking OK. You can also perform a controlled shutdown by pressing Ctrl+Alt+Delete at the same time, which will provide 
d the Windows Security dialog box. Here, you select Shut Down, then Shut down, and press OK. 
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Figure 7.4 A DHCP server that is not configured to automatically update DHCP client 
information in DNS. 


Windows 2000 DHCP Client Performing a Controlled Shutdown of 
Client Machine 


When a DHCP client performs a controlled shutdown and no longer has a presence on the net- 
work, there are no DHCP or DNS unregistration requests. The only unregistrations requests 
are for the NetBIOS names (assuming that your organizations is running a Windows Internet 
Name Service [WINS]). 


Figure 7.5 shows a Network Monitor capture of a DHCP client named Mustang performing a 
controlled shutdown. Notice that there are only seven frames that deal with the computer 
named Mustang. Six of these deal with unregistration requests and responses for NetBIOS 
names to a WINS server. The seventh packet (frame 6) is an SMB broadcast for 

Mailslot /Browser transaction. 


“| This action would be the same if a client computer were just powered off without doing a controlled shutdown. 


Because there is no traffic to the DHCP server or to the DNS server, both the host (A) and 
pointer (PTR) resource records are still registered with DNS. These resource records become 
stale because the client is no longer attached to the network. The resource records will not be 
removed from DNS unless the client is on the network when the DHCP lease expires. Because 
the DHCP server does not own either resource record, it cannot update the DNS server. 


When a client that has performed a controlled shutdown comes back up on the network, they 
will contact the DHCP server to renew their TCP/IP address, and they also will contact the 
DNS server to update both their host (A) and pointer (PTR) resource records. This allows any 
stale resource records to be updated even if the DHCP client obtains a new TCP/IP address. At 
this point, both resource records will be updated. Because the client was the original owner of 
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the stale resource records, they have the authority to remove the stale records and add the 
new registrations. 
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Figure 7.5 This is a capture (.cap) file of a DHCP client performing a controlled shutdown of 
a machine named MUSTANG. 


Figure 7.6 shows a Network Monitor capture (.cap) file of a client that has recently shut down 
and returns to the network at some later time. The client, named Mustang, is requesting the 
same address that it had prior to shutdown (the lease has not expired yet). Notice that there 
are only two DHCP frames for this transaction. One frame for the client Request (Frame 30) 
and one frame for the server ACK (Frame 31). (This capture has been filtered for Protocol == 
DHCP AND ANY <--> ANY.) 


Figure 7.7 shows a Network Monitor capture (.cap) file of the client Mustang, returning to 
the network and communicating with the DNS server to register/update both the host (A) 
and pointer (PTR) resource records. Frames 282 and 283 represent updating/response of 
the host (A) resource record with the DNS server. Frames 286 and 287 represent the 
updating/response of the pointer (PTR) resource record. This capture has been filtered for 
Protocol == DNS AND Local(Ethernet) <--> Mustang (IP). Local refers to the DHCP/DNS 
server and Mustang is the client computer. 
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| 3 Sro KE aad: | Dav HAC Addr P 
30 13.853375 kosmic ROADS DN P o Request 

2l 49eS9a7S LOCAL | -SBPOADCAST © DHCP -ACE o iwide2D722S1A} 
32 '43.875000 “FOREST © *BROADCAST DHCP HACR teddy 72Z5AR} 
Zsa 84.875000 LOCAL *BROLDCAST DECP Intorú l Co l qaddas Lever?) 
259 84.875000 “LOCAL “BROADCAST DHCP `. ACK DE txid=1614Ë0F7) 
261 -92.890625 ` LOCAL *BROADCAST DHCP Inform {zi4=00000000) 


=DECP: Request z trid=2D7ZZ5AA): ; 
“DHCP: Op Code top} Er SiS) 
DECP: Hardware Type- thtype} w 1o t0xl} - 10Mb Ethernet 
DHCP: Hardwares Address Length thlen} = :6 {0x5 
“DHCP: Hops a i thops) 20 {0x0} i : 
“DHCP: Transaction ID (abd) 6 oe 762488466 (O#2D 722544) 
DHCP: Seconds {secs} 0 {0x0} 
SBDHCP: Flags f {flags}. 
“DHCP: Client IP Address {oladdr) 
DHCP: Your IP Address (yiaddr} 
DHCP: Servar IP Address {siaddr} 
DHCP: Relay IP Address (qiaddr) 
DHCP: Client Bcthernet Address (chaddr) a “OOS008eB7K16 © 
DHCP: Server Host Name (sname) = <Blank> ee 
DHCP: Boot File Name {file}... = “<Blank> 
DHCP: Magic- Cookie = $9:1390:83.99 eee 
DHCP: Option Field foptions} 
DHCP: DHCP Message Type -= DHCP Request 
DHCP: Client-identi fier = tTypal 1) 00°60°08 8b Fa 16 
PHCP: Peiestend Address | =- Vas Teel d.i? 
: Host Name = pustang 


Tan Bew 
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Figure 7.6 This is a capture (.cap) file of a DHCP client renewing its TCP/IP address after a 
controlled shutdown and an active DHCP lease still remains. 


OsoOlt Netw) MtO > LIMON EAF TURES CHE ies 


a File Edt Display Tooke Options Wiedow Help 


LOR BLS 
10787 EL 
=" L080855. 
“108.03. 20: 
“108. 04... MUSTANG 


arrana: Base Erima proparties : axe Seen ARTE oos 
SPETHEPUET: - ETYPE = Ox0800":: Protocol = Tp: DOD Intemet Protocol: 

PIP: ID o 0x CEB; Proto: UDP; Len: 171 

UDP? Sre Ports DNS; (83) Dst Port: Unknown. (1060): Length m “151 (0x97) 


DNS: Query Identifier = 6: 10x6) ; 
aBDNS + DNS “Flags = Response, oproda = Dyn wd, “Roode - Ho: error 

DNS: Zone Cownt =" (0x1) 

DNS: Prerequisite Section Entry: Count = 1 toxi): 

DNS: Update- Section Entry Count = g (Oxz) ; 

DUS: Additional Records Count = 0 t00) i ! : : : Ue 
ADN: Update Zonet O0L168 L182 /din-addr: arpa: of cype Son om class: INET addr- 


DNS: Resource Names 12. 0.159:192.1n-+addr, arpa: 

DNS: Resource Type = Domain name pointer: 

DNS: Resource Class = Internet address class 
Si Time To Live = E00 toxsBo) 


DUS: “Resource Data Length = 42o (OxZA) 
Pointer: mustang- pellcancteer: home: bobcollier. org- 


Figure 7.7 This is a capture (.cap) file of a DHCP client returning to the network after a 


Ord: Dye ae PRE: records to: mustang. pelicant/.. : 
i Oxd:Dyn Upd Rasp: PRE. records to mustang. pe-. - 
OxS:Std Ory for 0168197. in~addr. arpa oF LL: 
“OxS:Std Qry Rasp. for :O-1685192/in-addrvarp. iiy 
Ox6:Dyn Upa PRE/UPD records to 12.0.168.1922.. 

Se a ea e 


DNS: oxe Dyn Upd Rasp. PREJ/UPD records: to i2. 021662192: in-addr- arpa. “of | type ponent cay nane a 


SpDNS: Prerequisite: 1250/168.192/in-addr_arpa: of type Canonical nane on class Unimiown Class ee ; 
“DNS: Update: AzSOl168. o dn addr. arpa: “of type Don. name per on elass Req.: for: ‘any (2 records present) 

DNS: Resource Record: 12.0. 168.192 in-addr. arpa, o£ ‘type Dom. name ptr on class Reg. for any 
DNS: Resourte Record: 12.0. 168/192: in-sddr arpa: of type: Dom. name ptr on class INET addr. 


shutdown has been accomplished and updating the DNS server for host (A) and 


pointer (PTR) resource records. 
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DHCP Client Performing an ipconfig /release and ipconfig /renew 


In this scenario, the client machine performs a release and renew of their TCP/IP address. 
This mechanism is the same mechanism as a client DHCP lease expiring and obtaining of a 
new DHCP client lease. 


When the client releases the TCP/IP address, it communicates with the DHCP server and does 
not wait for an ACK before it proceeds on to communicate with the DNS server to unregister 
both the host (A) and pointer (PTR) resource records. Figure 7.8 shows a Network Monitor 
capture (.cap) file of a client named Mustang releasing the TCP/IP address and unregistering 
both resource records in DNS. In this capture, Frame 1 is the release packet for the TCP/IP 
address. Frames 6 and 7 are the request to release the host (A) resource record and the 
response from the server. Frames 12 and 13 are the request to release the pointer (PTR) 
resource record and the response from the server. Notice in frame 13 that the Time To Live 
(TTL) is 0. This is a positive response that the DNS server has acknowledged the request and 
will delete the record from its database. 


DHCP -Release (xLdeGFCS299F} 
DNS Oxl?: Std Qry for mustang. pelicancreek-home-bobcollier.org.of ss: 
DNS Ox17:Std Ory- Resp: Auth. NS is pelicantraek homesbobcollier. ors. 
DNS Oxlé:Dyn Upd UPD records to mustang: pelicancreek-home-bobcolli... 
DNS Ox18:Dyn Upd Resp. UPD records to mustang pelicancreek home bo.: 
DNS OxSCAO:Dyn Upd UPD records to nustang.pelicancreek, home, bobeol... 
DNS OxSCA0: Dyn Upd Resp. UPD records to mustang. pelicancraaki home sss. 
DNS Oxl9:Scd Ory for 0.168.192 is-addrlarpa. of typa SOA dn class o-s. 
DNS Oris Sta Qry Resp: for 02168192 im-addy i arpa: of type SOR on oi: 
DNS Orlik: Dyn Upd UPD “records to 122021682192 -in-addrlarpas: of types: 
DNS OxlA: Dyn Upd Resp. UPD records. to 120051680192 in~addr arpa iors 
DNS Oxds70: Dyn Upad UPD records to 12.0: 168:192:in-addr arpa, of oeyoii 
IWSTANE DUS. DEDAS I PI pA -Kaspi UPD recurs re déc Lee LSS dn -addr arya. 


=DNS: OxD970: Pym Upa Resp. UPD eacords to 12. 0. L6651920in-addr arpa: of typa Dom: mame per 

ty Query Iaentirier =) 55664 -20xD970) 

tODNS “Flags = Response; OpCode = Dyn Upd; RCode = No error 

1 Some Count = 1- {04l} 

t Prerequisite Section Entry Count #0: (0x20) 

to Update Seevion Entry Count el {01} 

t Additional Records Count el {Ox1) 

t Update Zones 051662192. din-addr. arpa. of type SOL on class INET adar: 

: Update: 12.0 5166.192limn-sddrlarpal cof type Doms: mame per on class Unimown Class 
2 Resource Name: 12500168192 in-addr - arpa: 
> Resource “Type = Domain name pointer 
2 Resource’ Class = meri 

MNS Tame: Ta bave os 
i Resource Data spre a2 {ORSAY 
i: Podnter: mustang. pelicancreek- home bobcollier org: 

DNS? “Additional Records ‘Section: 99935319758673. of type Sere Rey Trans Sig on class Reg. for any 


Figure 7.8 This is a capture (.cap) file showing a DHCP client named Mustang releasing 
its TCP/IP address and unregistering the host (A) and pointer (PTR) resource 
records. 


Now that the client has released its TCP/IP address and unregistered its resource records, 
what happens when they renew their TCP/IP address? As you might expect, they perform the 
typical four broadcasts for a TCP/IP address. The four packets are 
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DHCP Discover broadcast from DHCP client 
DHCP Offer broadcast from DHCP server 
DHCP Request broadcast from DHCP client 
M DHCP ACK broadcast from DHCP server 


Figure 7.9 shows a Network Monitor capture (.cap) of a DHCP client broadcasting for a 
TCP/IP address. Frame 35 is the DHCP Discover, frame 36 is the DHCP Offer, frame 37 is the 
DHCP Request, and frame 38 is the DHCP ACK, which is the final packet in this sequence. 
Notice in frame 38 that the DHCP Options field provides the DHCP client with the TCP/IP 
address to the DNS server. (This capture (.cap) file has been filtered with Protocol == DHCP.) 


LOCAL DHCP) Release’). {xid=6FCS299F) 


BROA: A DHCP  Discovar : (xid=2688503E) : a 
WBROALL DHCP Offer (uid=zeaeso3gR) ESE ESE ow 
SBROAL.. DHCP Request => >o = o ttid=2600503E) ee ee oo 

aa aaa ea a eee 


Server Host Neme (sname) -= <Blank> 

DHCP: Boot File Name (ileyi ine <Blank>: 

DHCP: Magic Cookie = 5921390783099 

DHCP: Option Field i {options} i 
DHCP: DHCP Message Typa x PHCP- ACK SEAN 
DHCP: Renewal Tine Value: (Tl) =- 15- Days, 0:00:00 
DHCP: Rebinding Tina Value (T2) =:26 Days, -6200:00 
DHCP: IP “Address Lease Time =:.90 Days, 0:00:00 


DHCP: Server Identifier 192216820215 
DHCP: Subnet Haske m 255.255.2550 


DHCP: Domain: Name : i w: pealicancreak home. bobcollier.org 
2o Routar s La I6. 0. L : ee 

i: Denbain Nate Server: a: : : 
DHCP: NetBIOS Name Service 192. 1600021 
DHCP: NetBIOS Node Typa = {Length: 1) 08 
DHCP: Bnd ‘of this option: field 


oo IDHCE Message Option A e Lie 


Figure 7.9 This is a capture (.cap) file showing a DHCP client named Mustang broadcasting 
for a TCP/IP address and obtaining the TCP/IP address to the DNS server. 


After the DHCP client has its TCP/IP address and the TCP/IP address to the DNS server, it 
can now contact the DNS server and register both of its resource records. In Figure 7.10, the 
registration of both host (A) and pointer (PTR) resource records are accomplished between the 
DHCP client Mustang and the DNS server. Frames 23 and 24 show the registration and 
response of the host (A) resource record and frames 27 and 28 show the registration and 
response of the pointer (PTR) resource record. Notice in frame 28 that the Time To Live (TTL) 
is 1200, indicating that the DNS server has acknowledged the submission of the resource 
record. (This capture (.cap) file has been filtered in the following manner Protocol == DNS 
AND Local (Ethernet) <--> Mustang (Ethernet). Local refers to the DNS server and Mustang 
refers to the DHCP client.) 
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6.296875 Gaz: Dm Upa PRE regras t to mist ang: pelein., is2ii6r 
6.296975 = Oxl2:Dyn Upd Resp: PRE records to mustang. pv... WORKHOT | 
6.312500 y Oxl3: Std -Qry for 0.168.192 in adar arpa. ofc oLI2iI6E 
6.312500 Ox13:Sted Ary Rasp. for 0.168.192 sin~addrl ar... WORKHOT: | 
6.320125 : X: OxldsDyn Upa PRR/UPD records. to 14:0. 169- 19i 192.16€ — 
DE) 4 me i 


=DUS: orld: Dyn Tpd Resh: PRE/UPD secnrdE to vk 0. 168. 192. in~addr.arpa. of type Canonicai nane 
DNS: Query Tdenti fier: = 20 (0:14) 
PONS: DNS Flags = Response, OpCode ~ Dyn Upa, NCode ~ No error 
DNS: Zonë Count =:1 {0x1} 
DNS: Prerequisite Section Entry Count`= 1 {0x1} 
DNS: . Update Section Entry Count = 2 (0x2) 
DNS: Additions! Records Count = 6° (020) 
QDS: Update Zone: 0:5168.192 .imn~addr arpa. of type SOA on ‘class INET addr. 
“DNS: Prerequisite: 1410.168.192. 1in-addr. arpa.. of type Canonical hame on class Unknown ‘Class 
DNS: Resource Nama: 14.0.168.192.dn-addr. arpa. 
DNS: Rasource Type = Canonical nama for alias 
DNS:Rasource Class = Ox00FE 
DNS: Tine To Live oe 0- (0x0} 
DNS: Resource Data Length i=- 0:t0x0} 
eDNS: Update: 14.0.1602192-in-addr arpa: of type Doms name ptr on class: Req. for- amy(Z records present) 
DINS? Resource: Record: 14021682192 sin-addrvarpal of type Doms mame ptr ‘on class Rag. for ary 
sDNS: Resource Record: 1402168 .19Z im-addr arpa. of type Dom. name ptr on class INET: addr. 
2 -Resource Nane: 140.168. 192 .in-addrs arpa. 
rv Resource Type = Domain nana pointer 
> Resource Class = Internat address class 
NS: Tine Te Live = T20L (eden) 
z Resource Data Lengeh = 42 {Oxay 
žo Pointer:i mustang. pelicancreak. hone bobcoallieriorg.: 


Figure 7.10 This is a capture (.cap) file showing a DHCP client named Mustang registering 
its host (A) and pointer (PTR) resource records with the DNS server. 


This section has described the process that a Windows 2000 DHCP client will perform under 
different circumstances when the DHCP server is configured not to update client resource 
records. 


The next section will describe the process and interaction of both the DHCP client and DHCP 
server. 


DHCP Server Configured to Automatically Update DHCP Client 
Information in DNS and Update DNS Only If DHCP Client 
Requests 


When the DHCP server is configured to Automatically Update DHCP Client Request and the 
Update DNS Only If DHCP Client Requests is configured, as shown in Figure 7.11, the client 
updates the host (A) resource record and becomes the owner of that record, and the DHCP 
server registers the pointer (PTR) resource record and becomes the owner. This works out very 
nicely because when a client releases the TCP/IP address back to the DHCP server, they will 
contact the DNS server to unregister the host (A) resource record. Because the DHCP server 
registered the pointer (PTR) resource record, they have the responsibility of contacting the 
DNS server to unregister the record. This occurs when the DHCP client lease expires. 
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Figure 7.11 A DHCP server configured to automatically update DHCP client information 
and update DNS only if DHCP client requests. 


When the DHCP client obtains its TCP/IP address from the DHCP server, the client contacts 
the DNS server and registers its host (A) resource record and becomes the owner of that 
record. In a capture of the process, you would want to notice that the only traffic that you see 
between the client and the DNS server is for the host (A) resource record. There is no traffic 
shown for the registration of the pointer (PTR) resource record. Figure 7.12 is a capture (.cap) 
file of a DHCP client registering only the host (A) resource record. 


: Figure 7.12 does not show any traffic between the DHCP server and DNS server. This is because both the DHCP and DNS services 
are on the same server. If each service were on a separate server, you would see the appropriate traffic during a capture. 


You’ve seen the evidence with the capture (.cap) files. Now let’s take a look at the actual 
resource records and see exactly who owns which resource records. 


First, we will look at the host (A) resource record. I mentioned several times that because the 
DHCP client registers this record, they are the owner. This is important because only the 
owner has the authority to dynamically update and/or remove a record from DNS. Notice in 
Figure 7.13 that as we look at the properties of the host (A) resource record for the client 
named Mustang, we will discover in the Security tab that an account called MUSTANG$ 
(PELICAN\MUSTANGS$) has full control. 
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031250 oria: sta Ory for mustang: pelicancraek- home: dobablider: orgs of type SOR c | 
-046875 LOCAL MUSTANG DNS: (O0x19:Std Ory Resp. Anth. NS is pelicancreek.hone.bobcollidr. org. of typa i 
~062500 - MUSTANG. LOCAL PNS -Orli Dyn Upd PRE racords to mustang. pelicancraak.home.bobcollier. org: of | 
-062500 LOCAL BOUSTANG DNS OxLA: Dyn Upa Resp. PRE -recerds to mustang. pelicancréek- home. bobcollier. e 
13.218750 BUSTANG LOCAL °° “DNS 0I: Sta Ory for mustang. palicancreek. homes bobcolliex.org. of type SOA go 
2218750 - LOCAL MUSTANG DNS. OxlB:Std Ory Resp. Auth. NS is pelicancreek home. bobedllier-org: of type | 
216750  HOSTANG LOCAL. DNS --Oxlt: Dyn: Upa PRE/UPD records to mustang. pelicancreek. hone -bobcoliier:. org 
-234378 © LOCAL OMUSTANG DNS. -OxlC: Dyn Upd: Resp. PRE/UPD racords to mustang pelicancréek: home, bobeolli 
-250000 MUSTANG LOCALS © DNS © Oxg600: Sea Qry for 893353197586-3. of: type Sert Key Betb1 on class INET o 
-250000 MUSTANG LOCAL DNS- Ox?C76:Rsrvd Resp. io 
2268625 LOCAL HOUSTANG DNS OxB600: Sea ory Resp. for 693959197566-3. of cope Sert Rey Esthl on Gis | 
L281250 BUSTANG LOCAL Dus ‘Ox2498-Dyn: Upd  PRE/UPD records to. mustang. pelicancreak home-bobcollier:c a 
Uxcaso bm Upd Resp. PRESUPD records të mastang. pelicaneresk howe. LADEO a 
«625000 MUSTANG LOCAL DNS Ox: Std Ary- for workhorse pelicancreek- home. bebcollier org. of type Host. 
-625000 “LOCAL =. MUSTANG DNS .OxE:Std Qry Resp. for workhorse. pelicancreek- home -bobeollier org. of tyr | 


Figure 7.12 The capture (.cap) file of a DHCP client that is registering only its host (A) 
resource record. 


Admins (PELICANCREEK\Enterpris.... 
EPR ENTERPRISE DOMAIN CONTROLLERS 
EP Everyone aE 
Pa MUSTANGS [PELICANE FIEEK\MUS Tebi | 
ER PreWindows 2000 Compatible Access [PELIC. 


Figure 7.13 The security tab on the properties page of a host (A) resource record for a client 
named Mustang showing that the client has full control permissions for the 
resource record. 


If we take a look at the advanced properties for the Mustang$ account by selecting the 
Advanced button on the Security tab, and then select the Mustang$ account and click the 
View/Edit button, we can see that the account has Modify Owner and Modify Permissions. 
Figure 7.14 shows these advanced permissions. 
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Full Control 

List Contents 
Read All Properties 
AWwiite All Properties’ 
Delete 

Delete Subtree. 
‘Read Permissions 
Modily Permissions 
Modify Owner 

All Validated Writes 
All Extended Rights 


M 


z 
B 
z 
m 
z 
zl 
a 


o0o0o00000000 


Figure 7.14 The advanced special permissions for the Mustang$ account for the host (A) 
resource record shows us that the computer called mustang is actually the one 
that is registering the host record. 


To view the security tab on the properties page for either a host (A) or a pointer (PTR) resource record, the DNS zone must be 
Active Directory-integrated. 


Now that we have seen the host (A) resource record, we will take a look at the pointer (PTR) 
resource record that was registered by the DHCP server. Because this record was registered 
by the DHCP server, the owner of this record will be the DHCP server. Figure 7.15 shows the 
security tab on the properties page of the pointer (PTR) resource record for the same Mustang 
DHCP client. Notice that there is no MUSTANG$ (PELICAN\MUSTANG$) account that 
exists as part of this record. The DHCP client did not register this record and has absolutely 
no authority over the resource record. 


The significance of this is very simple. When a DHCP client shuts down, they do not unregis- 
ter their resource records from the DNS server, as was demonstrated in the previous section. 
Their records can become stale. Because the DHCP server has registered the client’s pointer 
(PTR) resource record, it has authority for that record to make changes as necessary. When 
the DHCP client lease expires, the DHCP server will remove the pointer (PTR) resource record 
from DNS. This will allow a more up-to-date database. 


138 Chapter 7 Configuring DNS Clients 


ame. 
Enterprise Admire (PELICANCREEK\Entetpris:.. 
ENTERPRISE DOMAIN CONTROLLERS 


Everone 
Pre-Windows 2000 Compatible Access (PELIC.. 


Figure 7.15 The permissions on a pointer (PTR) resource record that was registered by the 
DHCP server. 


DHCP Server Is Configured to Automatically Update DHCP Client 
Information in DNS and to Always Update DNS 


If the DHCP server is configured to Automatically Update DHCP Client Information in DNS 
and to Always Update DNS, then the DHCP server will always update both the host (A) and 
pointer (PTR) resource records, as shown in Figure 7.16. This makes the DHCP server the 
owner of both records and provides the responsibility to remove those resource records from 
the DNS server. The DHCP server will remove both resource records from DNS when the 
DHCP client’s TCP/IP lease expires. This prevents resource records from remaining in DNS 
after a client’s lease has expired. Because the DHCP server should always be on the network, 
both resource records can be removed when the DHCP client lease expires. 


In this scenario, the DHCP client does not register the host (A) or the pointer (PTR) resource 
records with DNS. In Figure 7.17, you notice a DHCP client named Mustang has obtained a 
TCP/IP address and has registered NetBIOS names with the WINS server. There is no com- 
munication between Mustang and the DNS server. However, the DHCP server (local) sends 
queries to the DNS server on a machine named testw2k. You can see the update registrations 
for both resource records. 


@ In Figure 7.17, Frames 1—4 show the DHCP client named Mustang obtaining a TCP/IP 
address from the DHCP server (local). 


E Frames 5 and 6 show the DHCP server (local) performing a standard query for the host 
(A) resource record mustang.pelicancreek.home.bobcollier.org and response from the DNS 
server (testw2k). 


E Frames 7 and 8 show the update of the host (A) resource record for mustang. 
pelicancreek.home.bobcollier.org from the DHCP server (local) to the DNS server 
(testw2k) and response. 


Figure 7.16 


Figure 7.17 


E Frames 9 and 10 show the DHCP server (local) performing a standard query for the 
pointer (PTR) resource record to the DNS server (testw2k) and the response. 
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This figure shows a DHCP server that is configured to automatically update 
DHCP client information and to always update DNS. 


SE 298O75 -i ANG BROADCAST “DHCP oo Discover: a l BAL) 
5, 812500 ©  WBROADCAST = «- -DHCR = Offer (de 58150341) 
“BL@LZ500 oo) SBROADCAST (0) ee Request oo tebdeSB1LSO3RLP 
“53812500 = 2S SBR ORDEAST oo: 22 AROS Soo {eh SOLSOSAL) wees 
$.812500 -Li CS PES TIZR Fo So pulir Sed Qry for mustang. pelicancreek home. b,n. 
“82928125 CN GORE SS YS oe mk ae OAuth: NS ds pelicancraek. 22. 
i < TESTER SNe 4 ND xorords to mastani. pela. 

BOOMER BN Oe ees Dre Dpd Resp.. PRE/UPD records to mustan... 
51828125: LC OSS OBS TIMBRE E A pooo Onz9i Std Ory for 0.168.192. in-addr. erpa. of ii 
O22!) Sl eze1Zs  BOCAL = PWS OZ9=Std Ory Resp. for 0.168.192.in-addr.arp.. 
1i -51843750 N poe SBROADCAST i ARP_RARP ARP: Request, Target IP: 192.168.0.14 
L200 5.849750 AE opEsTMeR © eet ee Sethe Dyn’ Upd UPD: records to 14021682192 an= 
AB Sl 949980 “ORES DAD Sines 21°85" Og0tMotdéy for 0.1685192-in<addr arpa. of tyi" 
D4 8843750 TRSTMAR oo O LOCAL Oo So ORA Dyn Upd Resp. UPD records to 14.0.168.1... 
1S 9-8 e90625 MUSTANG 000 *BROADCAST ` i “ARP: Request, Targat IP: 192116810114 : 


1g 6.890625 MUSTANG ss “BROADCAST -ARP RARP ARP: Request, Target IP: 192.168.0-14_ 

LP OF ezaz O LOCAL Oo eB ROADCAST 0 oo Inform: pene (tideopo00000) 

1S 7 B2B1ZS LOCAL 0 *BROADCAST | ROR Joo (aide00000000} 
19 PLSZ1O7S MUSTANG 0 LOCAL” “WS: Registration req. for MUSTANG © <400> e 
20° °° 7.921875 BUSTANG 9 LOCAL 5 “NS: Refresh reg: for IS-HUSTANCG<00...(6)> 

BL 7981075 LOCAL 200000 “BROADCAST ARP: Request, Target IP: 19211687014 
22921878 MUSTANG 0S LOCALS ARP: Reply, Targat IP: 192/168.0.1 Target Ha... 
29000 F2921875 LOCAL! 00 MOSTANG OHS: Registration (Node Status) resp. for MUS... 
2400 0-7.921875 LOCAL 3 MUSTANG» WS: Registration (Node Status) resp. for IS~... 
BB oS F921 O78 HOSTANG oe LOCAL oii “ONS: Refresh reg: for IMet~Services  <10> onii 
2671921875 LOCAL = MUSTANG “OMS: Registration (Mode Status) resp. for INe... 
27-0 -e@s187500 NUSTANG °° LOCAL © ONS: Registration rag.: for PELICANCREER = <00> 06000 
2882187500 - LOCAL MUSTANG “OMS? Registration (Hode Status) resp. for PRLS 
29-00 -8LZ031Z5 | MUSTANG BOCK: NS: Registration rag. for HUSTANG 200000. ae 
B00 BL 203125 LOCAL STATE O Ne: Registration (Mode Status) “resp. for BUSI.. 


BL 82208125 9 MUSTANG 20000 LOCAL 


OWS: Registration reg. for PELICANCREEK = <1E> mt 


internet Domain Name System Packe E 7/98 


The capture (.cap) file of a DHCP client requesting a TCP/IP address from a 
DHCP server that is configured to automatically update DHCP client requests 


and to always update DNS. 
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M@ Frames 12 and 14 show the DHCP server (local) updating the pointer (PTR) resource 
record for 14.0.168.192.in-addr.arpa (this is the TCP/IP address of mustang) with the 
DNS server (testw2k) and the response. 


This is the process of DNS name registration when the DHCP server handles all the registra- 
tions. If we take a look at the actual resource record in DNS and look at the ownership of the 
resource records, we will see that the DHCP server has authority for both the host (A) and 
pointer (PTR) resource records. Figure 7.18 shows that the DHCP client does not have author- 
ity for either of the resource records. In the security tab, you will notice that there is no refer- 
ence to the machine Mustang. The client did not register its own host (A) or pointer (PTR) 
resource records. 
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| [ER Exchange Servers (HOMESS19\Exchange Se... 
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Figure 7.18 The Security tab on the properties page of the host (A) resource record shows 
no indication that mustang has any authority for the resource record. 


We've discussed different scenarios for a Windows 2000 DHCP client and how the registration 
of host (A) and pointer (PTR) resource records takes place. The next section will describe how 
Windows 2000 non-DHCP clients register their resource records with the DNS server. 


Statically Configured Windows 2000 Client 


When a Windows 2000 client is statically configured for TCP/IP and has the TCP/IP address to 
a DNS server, the client will register both host (A) and pointer (PTR) resource records with its 
specified DNS server. Remember here there is no interaction with the DHCP server, but the 
client’s machine is still running the DHCP client service. The DHCP client service is actually 
responsible for attempting to dynamically register with DNS. Figure 7.19 shows a Network 
Monitor capture (.cap) of a client named mustang registering both host (A) and pointer (PTR) 
resource records with the DNS server. 
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Figure 7.19 A capture ee file of a statically Se TCP/IP client dynamically 
registering with DNS. 


Notice in Figure 7.19 that client Mustang registers the host (A) resource record in frame 295 
and gets the response in frame 296. Frames 299 and 300 show the registration and response of 
the pointer (PTR) resource record. Again notice the Time To Live (TTL) of the resource record 
in frame 300. (This capture (.cap) file has been filtered using Protocol == DNS AND 
Local(Ethernet) <--> Mustang(Ethernet). Local refers to the DNS server and Mustang refers to 
the DHCP client.) 


A Windows 2000 client also can register information to DNS by using the ipconfig/registerdns 
switch. This will force an update between the client and the DNS server. 


A statically configured TCP/IP client will not contact the DNS server when it does a controlled 
shutdown. This can cause some records to become stale in DNS if the client is off the network 
for a long period of time (as when they are turned off for the weekend). When the client starts 
up, it will again reregister both host (A) and pointer (PTR) resource records. 


Remote Access Server Clients 


The RAS client reacts much the same way as a statically configured TCP/IP client. There is 
no interaction between the RAS client and the DHCP server. This means the RAS client is 
responsible for dynamically updating both host (A) and pointer (PTR) resource records. The 
main difference here is the RAS client will attempt to delete both host (A) and pointer (PTR) 
resource records before closing the connection. If the attempt to delete the resource records 
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should fail for some reason, then the records will become stale. In the event that the RAS 
connection is lost, then, again, the resource records can become stale. In both cases, the RAS 
server will attempt to unregister the pointer (PTR) resource record. This still leaves the 


host (A) resource record on the DNS server until the client reconnects and reregisters 
with DNS. 


Windows 2000 Secure Dynamic Updates 


One of the advantages of the Windows 2000 environment is the enhanced security features. In 
Windows 2000, DNS can be configured to allow secure dynamic updates. This will work only if 
the DNS zone is Active Directory—integrated. The security control mechanism is controlled 
through Access Control Lists (ACLs). The ACLs control access to the secure DNS zone and reg- 
istered names in them. The ACLs can be specified on a zone-per-zone basis or modified for spe- 
cific resource records within a zone. By default, any authenticated user has the authority to 
create a host (A) and pointer (PTR) resource record in any zone. When a user creates a 
resource record entry, they are tagged as the owner for that record. Only users or groups that 
are identified in the ACL as having the write permission will be allowed to update or modify 
the resource record. By default, if a client registers a resource record, they have the write per- 
mission for that resource record. 


We've mentioned that allowing the DHCP server to register both host (A) and pointer (PTR) 
resource records for DHCP clients can cause stale records in DNS because the DHCP server 
becomes the owner. The DHCP server will not unregister the resource records until the DHCP 
client lease expires. Windows 2000 has provided a solution to this problem with the introduc- 
tion of a new group called DnsUpdateProxy. Any resource record that is registered by a mem- 
ber of this group has no security. The first user that is not a member of this group that 
touches the resource record becomes the owner and has the authority to modify the resource 
record. The DnsUpdateProxy group can be managed through the Active Directory Manager. 
Figure 7.20 shows the DnsUpdateProxy group listed in Active Directory Manager. 


Windows 2000 DHCP servers that will be responsible for registering DNS names for clients 
should be added as a member of this group. Figure 7.21 shows the Members listing for the 
DnsUpdateProxy group. Although this solution resolves the issue of having stale resource 
records in DNS, it does open some potential security holes. Any DNS names registered 
through the DnsUpdateProxy group are nonsecure, which means there is a chance for tamper- 
ing. This becomes even more of an issue if the DHCP server is on a Domain Controller. All 
resource records that are registered like the service location (SRV), host (A), or alias (CNAME) 
for the domain controller are nonsecure. To resolve this issue, do not place the DHCP server 
on a Domain Controller. 
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Figure 7.20 The DnsUpdateProxy group in the Active Directory Manager is used by DHCP 
= in Windows 2000 to register host records without putting in a security context. 


Figure 7.21 The Members property page displays all members of this group. 


Let’s take a look at the sequence of events that occur in the secure dynamic update process. 
Figure 7.22 shows a diagram of the secure dynamic update process. Each step will be 


described next. 
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Figure 7.22 The sequence of events during a secure dynamic update process. 


The sequence of events for the secure dynamic update process is as follows: 


1. The client computer performs a query to the local DNS server to discover where the 
authoritative server is for the name that it is attempting to register/update. The local 
DNS server responds with the information for the authoritative server. Figure 7.23 
shows a Network Monitor capture (.cap) of the query and response from a client named 
Mustang for the authoritative server. 


Frames 15 and 16 are the query and response. Notice in frame 16 under the DNS: 
Authority Section that the Active Directory Server information is returned, and in the 
DNS: Additional Records Section, the TCP/IP address for the authoritative server is also 
returned. 


_| All the Network Monitor capture (.cap) files have been filtered in the following manner: Protocol == DNS AND Local (Ethernet) 
_. <--> Mustang (Ethernet). Local refers to the DNS server and Mustang refers to the DHCP client. 


2. The client (mustang) next queries the authoritative server 


(workhorse. pelicancreek.home.bobcollier.org) and receives a successful reply. Refer to 
Figure 7.24, frames 19 and 20. 


3. 
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After the client verifies the authoritative server, it attempts to perform a nonsecure 
update. The server will return an operation-refused response. This is an expected 
response for an Active Directory—integrated DNS zone configured for only secure 
updates. Figure 7.24 shows the client (mustang) attempting a nonsecure update to the 
authoritative DNS server and receiving an operation-refused response. 
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Figure 7.23 A capture (.cap) of client’s query to and response from a DNS server for the 


authoritative server. 


Frames 21 and 24 show the attempt from mustang to perform a nonsecure update and 
the operation-refused response from the authoritative server for the 
pelicancreek.home.bobcollier.org zone. Notice in frame 24 in the DNS: DNS Flags that 
the response is operation refused. 


This begins the client/server security context negotiation in which they exchange one or 
more security tokens using the TKEY resource record as the vehicle to transfer security 
tokens between them. Figure 7.25 shows the initial negotiation of security keys using 
Kerberos security context. 


The TKEY is a Kerberos implementation for security context that basically replaces the use of the SID that was used in 
Windows NT 4.0. 


Frames 35 and 36 are from the client mustang initiating the security context negotiation 
with the authoritative server. Frame 38 is the positive response from the authoritative 
server. Notice all the cryptic additional information with the security context establish- 
ment. Frames 43 and 44 are the secure update request for the host (A) resource record. 
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Figure 7.24 A capture (.cap) file showing an attempt to perform a nonsecure update with an 
operation-refused response. 
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Figure 7.25 A capture (.cap) file of the security context negotiation between a client and the 
authoritative server. 
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5. Now that the client and authoritative server have established their security context, the 
client sends the signed dynamic update to the authoritative server. 


6. The authoritative server attempts to update Active Directory. When the authoritative 
server attempts to update the Active Directory, it must first check to see whether the 
client has the appropriate permissions to make the update and that all prerequisites 
have been met. 


7. The authoritative server sends a response back to the client. The response is either No 
Error or Operation Refused, depending on whether it was able to successfully update 
Active Directory. 


Windows 2000 DHCP Clients Using a Windows NT 4.0 
DHCP Server 


What happens if your organization is still using a Windows NT 4.0 DHCP server? Windows 
NT 4.0 DHCP servers do not support dynamic updates, so the Windows 2000 client will have 
to update both the host (A) and pointer (PTR) resource records. 


The process is the same process as if the Windows 2000 client were statically configured for 
TCP/IP. If the DNS zone were Active Directory—integrated, then the secure update process 
would be the same as discussed in the previous section. 


This section has discussed several scenarios and configuration options for dynamic updates to 
DNS from the Windows 2000 client. The process is true for all Windows 2000 client operating 
systems, from Windows 2000 Professional to Windows 2000 Data Center Server. 


Most organizations will want to take advantage of the secure dynamic updates that Windows 
2000 has to offer. To fully realize the benefits of secure dynamic updates, an organization 
should seriously consider moving all their clients to Windows 2000. 


Like any other network service, the proper planning, configuration, and implementation con- 
siderations will be crucial to successful deployment. 


Windows 9.X Clients 


Your organization still has Windows 95/98 clients? You are probably wondering how this will 
affect your ability to dynamically update DNS with the TCP/IP addresses of these down-level 
clients. Windows 2000 DHCP servers have the ability to update DNS with down-level client 
registrations. There are basically two options that are currently available in Windows 2000. 
We will discuss both positive and negative aspects of both and will also discuss some options 
that might be available in future updates to the Windows 2000 OS. 


The term down-level client refers to any client that is not a Windows 2000 client that supports being a DHCP client (such as 
-Windows NT 4.0, Windows 98, Windows 95). 
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Dynamic Registration of Pointer (PTR) Resource 
Records for Down-Level Clients 

By default, down-level clients do not have the capability of dynamically registering their 
TCP/IP addresses with a Windows 2000 DNS server. To enable this functionality, you will need 


to make a modification to the configuration of the Windows 2000 DHCP server as shown in 
Figure 7.26. 


Figure 7.26 The DNS tab of the Scope dialog box where you select Enable Updates for DNS 
Clients That Do Not Support Dynamic Update. 


To enable the dynamic registration of DNS resource records for down-level clients, you must 
perform the following steps: 


1. Open the DHCP manager. 

In DHCP manager, select the scope that you want to modify. 
On the Action menu, click Properties. 

This presents the Scope dialog box; select the DNS tab. 


In the DNS tab, check the box next to Enable Updates for DNS Clients That Do Not 
Support Dynamic Update. 


Pe ee 


This configuration will allow the dynamic update of pointer (PTR) resource records with a 
Windows 2000 DNS server. 


Notice in Figure 7.26 that the Automatically Update DHCP Client Information in DNS is 
selected and the Update DNS Only If DHCP Client Requests option is selected. With this 
configuration, host (A) resource records are not registered. The documentation that is 
provided with the online books suggests that the DHCP server will register both host (A) and 
pointer (PTR) resource records with this configuration. This is not the case. 
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Registration of pointer (PTR) resource records should be sufficient in an organization for find- 
ing hosts. Pinging a down-level host by the hostname results in successful replies. This sug- 
gests that registration of only the pointer (PTR) resource record is adequate. 


When the client lease expires, the DHCP server will unregister the resource record. 


Dynamic Registration of Host (A) and Pointer (PTR) 
Resource Records for Down-Level Clients 


It is also possible to have DHCP register both host (A) and pointer (PTR) resource records for 
down-level DHCP clients. The configuration is similar to the previous section. In addition to 
selecting Enable Updates for DNS Clients That Do Not Support Dynamic Update, you also 
will need to select the Always Update DNS option in the DNS tab of the Scope dialog box in 
DHCP Manager. Figure 7.27 shows the appropriate configuration. 
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Figure 7.27 The proper configuration to allow DHCP servers to dynamically update both 
host (A) and pointer (PTR) resource records in DNS for down-level clients. 


This configuration will work, but when you configure the DHCP server in this manner, it will 
also always update DNS for the Windows 2000 DHCP clients. This can cause stale resource 
records to reside in the DNS server. The DHCP server will unregister resource records when 
the DHCP client’s lease expires. 


An option that may be available in the near future is the ability to create classes of DHCP 
clients. The option is actually already built in to Windows 2000. The options that are available 
and have predefined options are 
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E DHCP Standard Options—These include the familiar options that Windows NT 4.0 
DHCP servers have: 


003 Router 

006 DNS servers 

044 WINS/NBNS servers 

046 WINS/NBT Node type 

069 Simple Mail Transport Protocol (SMTP) servers 
070 Post Office Protocol version 3 (POP8) server 
072 World Wide Web (WWW) servers 


Æ Microsoft Options—tThese options are for Microsoft clients that support these options, 
such as Windows 2000 and Windows 98. The three options that you have are 


001 Microsoft Disable NetBIOS Option 
002 Microsoft Release DHCP Lease on Shutdown Option 
003 Microsoft Default Router Metric Base 


E Microsoft Windows 2000 Options—tThese options are specifically supported by 
Windows 2000 DHCP clients and include 


001 Microsoft Disable NetBIOS Option 
002 Microsoft Release DHCP Lease on Shutdown Option 
003 Microsoft Default Router Metric Base 


E Microsoft Windows 98 Options—These are supposed to be options specific to 
Windows 98 clients. There currently are no defined options. Figure 7.28 shows the 
Windows 98 options dialog box. You do have the ability to create and define your own 
options. For information on this, see the online books or visit http: //www.microsoft.com 
to find technical papers on creating your own vendor or user-defined options. 


There is currently a Directory Service client for Windows 95/98 that allows a Windows 95/98 
client to interact with Active Directory. For instance, if you wanted to have user level access 
in Windows 98 and the domain controller was a Windows 2000 server, you could install this 
client and access the directory services database in Active Directory. This client also would 
allow you to access DFS on a Windows 2000 server. Figure 7.29 shows a Windows 98 client 
that has been set for User-Level Access assigning permissions to a shared folder. 


This client does not add any additional functionality to the ability of dynamically 
updating DNS. 
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Figure 7.28 The options box for the Windows 98 server options in DHCP Manager without 
any predefined options. 


< Betsie 


Domain users 
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Figure 7.29 A Windows 98 client that has been set for User-Level Access assigning 
permissions to a shared folder. 


Other Clients 


One last item to mention is that, for Windows NT 4.0 clients, there is currently no mechanism 
for them to access Active Directory. There is speculation that Microsoft will provide an Active 
Directory client for Windows NT 4.0 machines when they release Windows NT 4.0 Service 
Pack 7. At press time, there is no word about when Service Pack 7 will be released and what 
functionality it will provide. 
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Other non-Active Directory clients that have the ability to obtain a DHCP lease from a 
Windows 2000 DHCP server will be dynamically registered like any other down-level client. 
For clients that are not DHCP enabled, administrators will have to manually enter the 
resource record information into the DNS server. As Windows 2000 matures and takes its 
place in the world of enterprise networking, more functionality is sure to come. 


EXPLORING RESOURCE 
RECORDS 


Resource records are used within DNS to define services, define hosts, and 
allow resolution of hosts into TCP/IP addresses. This chapter will describe 
the most commonly used resource records: A, AAAA, CNAME, MX, PTR, 
and SRV. We will discuss formatting and syntax, functionality, proper 
usage, and who can create or modify a particular resource record. There are 
more resource records that can be utilized but are not common to most DNS 
organizations. At the end of this chapter, we will identify some additional 
resource records along with the appropriate Request For Comments (RFC) 
documentation that describes them. 


Format of DNS Resource Records 


Each resource record has a specified format that uses the same top-level 
fields. These fields are described in RFC 1035. The fields are 


fH Name or Owner—This is the name of the record that you are 
identifying—a domain name to which this resource record pertains. 
For example, mustang.pelicancreek.home.bobcollier.org designates the 
hostname and the domain name where this host can be found. 


HM tType—This field contains two octets of mnemonic text that indicate 
what type of resource record this is. This field also specifies the mean- 
ing of the data in the RDATA field. Table 8.1 shows examples of some of 
the different types of resource records. 
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Table 8.1 Standard Resource Record Types and Values 


Type Value and Meaning 

A 1, a host address 

NS 2, an authoritative name server 

CNAME 5, the canonical name for an alias 

SOA 6, designates the start of a zone of authority 

PTR 12, a domain name pointer for reverse lookups 

HINFO 13, host information 

MINFO 14, mailbox or mail list information 

MX 15, mail exchanger to designate a server as a mail server 

Æ Class—This field contains two octets of mnemonic text that describe which class of the 


data is in the RDATA field. The most common implementation is IN, which indicates the 
resource record belongs to the Internet class. This is the only class of resource records 
that is supported by Windows 2000 DNS servers. Table 8.2 shows the classes of resource 
records. 


‘Table 8.2 Classes of Resource Records 


Class Value and Meaning 

IN 1, Internet class 

cs 2, CSNET; this class is obsolete and used only as a reference in older RFCs. 
CH 3, CHAOS class; in most cases this class is no longer used. 

HS 4, HESIOD class; confined mostly to MIT. 

Æ tt_—tThis field contains a signed 32-bit integer specifying the time interval that a 


resource record will be maintained in cache before it becomes stale or is discarded. A 
zero value would indicate that the resource record should not be cached at all and is 
only valid for the current transaction. This field is optional for most resource records 
and will normally inherit the default value of one hour from the SOA record when the 
resource record is created by the DNS server. 


RDLENGTH—This field contains an unsigned 16-bit integer specifying the number of octets 
in the RDATA field 


RDATA—This field contains a variable length string of octets which describes the resource 
that is being indicated. The formatting for this field is specific to the TYPE and CLASS of 
the resource record. If the resource record TYPE is A and the CLASS is IN, the RDATA field 
would be a 4-octet ARPA Internet address. 


We have described the formatting process of the resource records. To look at the formatting of 
resource records, you can look at the properties of any resource record in the DNS manage- 
ment console, or you can look at the actual DNS file from the %systemroot%\system32\DNS direc- 
tory structure. This is where all non-Active Directory DNS zone files are stored. 
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_ W2K Supports for Classes 
_ Because Windows 2000 only accepts the IN class of records, many of the resource records will not designate the class. It is 
assumed that if the SOA resource record is of the IN class, all resource records for that zone are also of the IN class. 


The remaining components of this chapter will focus on individual resource records and their 
specific data. 


A Resource Records 


Host (A) resource records are used to map domain computer names (hostnames) to IP v4 
addresses (32-bit address). Host (A) records comprise most of the resource records in a zone. 
They are used primarily to identify computers that share resources on a network. RFC 1035 
describes this resource record (page 20). The syntax for an A resource record is 


Owner ttl class A IP_v4 address 


An example of an (A) resource record Windows 2000 property sheet is shown in Figure 8.1 and 
would look like the following: 


mustang 600 IN A 192.168.0.17 


Figure 8.1 The properties page for the “(A)” resource record of a host named mustang in 
Windows 2000 displays the hostname and TCP/IP address of the host. 
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In Windows 2000, (A) resource records can be added to a DNS server in several ways: 


@ Through the DNS console, you can manually add Host (A) resource records for hosts 
that have static IP addresses. 


© A qualified DHCP Server can update Host (A) resource records for DHCP-enabled clients 
of non—Windows 2000 Microsoft operating systems that obtain their IP address from the 
DHCP server. Currently, only Windows 2000 DHCP servers support this feature. 
Examples of the non—Windows 2000 DCHP clients would be Windows NT 4.0 and ear- 
lier, Windows 95/98, and Windows 3.x supporting DHCP clients. 


=E Windows 2000 computers that are DHCP-enabled clients can dynamically register and 
update their own Host (A) resource records. This happens when they first obtain a 
DHCP lease, if there are changes to their IP address configuration, or when they release 
their DHCP lease. 


When a host registers its (A) resource record, it becomes the “owner” for that record. Only the 
owner of a resource record can modify the registration of or delete the resource record from the 
DNS server. You can refer to Chapter 7, “Configuring DNS Clients,” for detailed information 
on ownership of resource records. 


_ Use of Internal Server 

. Registration of Host (A) resource records for clients on a network is best done with an internal DNS server. For most networks, 
| registration of Host (A) resource records could potentially compromise network security by allowing external people access to 
| information of internal hosts. 


AAAA Resource Records 


AAAA resource records are used to map domain computer names (hostnames) to IP v6 
addresses (128-bit addresses). This resource record is fairly uncommon to date, but will 
become more common as soon as IP v6 is fully implemented around the year 2002. 

RFC 1884 describes the architecture of IP v6 and RFC 1886 describes the DNS extensions 

to support IP v6. Currently, Windows 2000 does not support IP v6 resource records. However, 
a research development version of IP v6 can be downloaded from Microsoft at 
http://research.microsoft.com/msripv6/. 


IP v6 addresses are 128-bit identifiers for interfaces and sets of interfaces. There are three 
types of addresses (described in RFC 1884): 


HM Unicast—This is an identifier for a single interface. A packet sent to this address is sent 
to the interface directly. 


M7 Anycast—This is an identifier for a set of interfaces (typically on different nodes or 
hosts). A packet sent to this address is delivered to one of the interfaces identified, usu- 
ally the nearest one as defined by the routing protocol. 
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W Multicast—This is an identifier for a set of interfaces (typically on different nodes or 
hosts). A packet sent to this address is delivered to all interfaces that are identified. 


The text representation of IP v6 addresses can be shown in three conventional forms (defined 
in RFC 1884) : 


Æ x:x:x:x:x:x:x:x—This format is the preferred method of annotating IP v6 addresses. The 
xs represent the hexadecimal values of the eight 16-bit sections of the address. Table 8.3 
shows a comparison of a hexadecimal address to the decimal and binary values. 


Table 8.3 Comparison of Hexadecimal, Decimal, and Binary Values for IP v6 Resource Records 


Address: FEDC:BA98:7654:3210:FEDC:BA98:7654:3210 


Hexadecimal Decimal Binary 
FEDC 65244 1111111011011100 
BA98 47768 1011101010011000 
7654 30292 0111011001010100 
3210 12816 0011001000010000 
FEDC 65244 1111111011011100 
BA98 47768 1011101010011000 
7654 30292 0111011001010100 
3210 12816 0011001000010000 
Address: 1080:0:0:0:8:800:200C:417A 
Hexadecimal Decimal Binary 
1080 4224 0001000010000000 
0 0 0000000000000000 
0 0 0000000000000000 
0 0 0000000000000000 
8 8 0000000000001000 
800 2048 0000100000000000 
200C 8204 0010000000001100 
417A 1676 0100000101111010 
WE ::—Some IP v6 addresses can contain long strings of zeros bits. To make the writing of 


these addresses easier, a special syntax is available to compress the zeros. The use of :: 
indicates multiple groups of 16-bit zeros. This special syntax can only appear once in an 
address. Table 8.4 shows how addresses with multiple groups of 16-bit zeros can be writ- 
ten with the special syntax. 
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Table 8.4 Using :: for Multiple Zeros in IP v6 Addresses 


Natural Form of IP v6 Addresses Address Using Special Syntax 
1080:0:0:0:8:800:200C:417A 1080::8:800:200C:417A Unicast 
FF01:0:0:0:0:0:0:43 FF01::43 Multicast 
0:0:0:0:0:0:0:1 ::1 loopback address 
0:0:0:0:0:0:0:0 | :: Unspecified address 


W x:x:x:x:x:x:d.d.d.d—This is an alternative form that can be used in mixed environ- 
ments of IP v4 and IP v6. The xs represent the hexadecimal values of the six high-order, 
16-bit sections of the address, and the ds are the decimal values of the four low-order, 
8-bit pieces of the address. Table 8.5 provides examples of using this alternative form. 


Table 8.5 Alternative Format for Integrating IP v6 and IP v4 


Alternative Form Compressed Alternative Form 
0:0:0:0:0:0:192.168.0.17 ::192.168.0.17 
0:0:0:0:0:FFFF:192.168.0.1 :FFFF:192.168.0.1 


The AAAA resource record has been included in this book to give DNS administrators a head 
start on learning about IP v6 resource records. This resource record type will become much 
more predominant in the near future. More information about this resource record can be 
found in RFC 1884 and RFC 1886. A good site for RFCs relating to DNS is http: / /ww. 
pop-uc.rcts.pt/mirrors/dnsrd/docs/rfc.html. You can access most of the RFCs that pertain to 
DNS from this site. 


Windows 2000 will be RFC 1884/1886—compliant when Microsoft implements its version of IP 
v6. As of print time, Microsoft has a research version (1.4) of IP v6 that can be downloaded 
and installed. This product is not intended or supported for production environments. 
Documentation and source code are available for download as well. The documentation will 
provide an overview of configuration and commands supported with IP v6. The documentation 
will also provide information about how to configure compatibility between IP v4 and IP v6. 
Again, the URL is http://research.microsoft.com/msripv6/. 


CNAME Resource Records 


Canonical name, or CNAME, resource records, also called alias resource records, map aliases 
or alternate domain names to the true domain names. CNAME resource records allow the 
mapping of more than one name to a single host. The canonical or primary DNS domain used 
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in the data is required and must resolve to a valid DNS domain name in the namespace. RFC 
1035 (page 14) describes CNAME resource records. The following is the syntax for a CNAME 
resource record: 


Owner ttl class CNAME canonical name 


A sample CNAME resource record would look like the following: 


ia 
LL 
Le 


Forest 600 IN CNAME pelican.home.org 
ftp 21600 IN CNAME pelican.home.org 
bob CNAME ftp.pelicancreek.home.bobcollier.org 


Use of TTL with CNAME Resource Records 
Not all resource records have to have a ttl or need to have the Class identified in the resource record. If the ttl is not identi- 
fied, the ttl takes the default time from the SOA. The Class is also implied by the SOA. 


The following are the recommended uses of canonical resource records: 


E Renaming a host resource record within the zone—A canonical resource record can be 
used for temporary resolution to a new hostname. Suppose, for example, you have a host 
called forest in the home.org zone, and you want to rename the host to pelican. To do so, 
create a Host (A) resource record for pelican and then create a CNAME resource record 
for forest that points to the new Host (A) resource record of pelican. You can now get rid 
of the original Host (A) record of forest. The result of this is as follows: Users trying to 
resolve pelican will be resolved to the new Host (A) record of pelican, users that try to 
resolve to forest will be resolved to the new Host (A) record of pelican. 


E Mapping a permanent alias name to a server that provides different services—The best 
example, shown in Figure 8.2, is a Web server that hosts www and FTP sites. To make 
resolution simple, you can create the Host (A) resource record for the Web server, called 
web.pelicancreek.home.bobcollier.org and map it to the appropriate IP address. Next, 
create a CNAME resource record called FTP and map it to web. pelicancreek.home. 
bobcollier.org, and then create another CNAME resource record called www and map 
it to web. pelicancreek.home.bobcollier.org. Now, both www and ftp will map to the 
single server called web.pelicancreek.home.bobcollier.org. 
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Figure 8.2 Using nslookup, you can query a CNAME resource record and see that both 
the CNAME resource records of ftp and www map to the same host called 
web.pelicancreek.home.bobcollier.org. Notice the highlighted text. 


MX Resource Records 


Mail exchanger (MX) resource records provide message routing to a mail exchanger host (mail 
server), as specified in the owner field. MX resource records use a two-digit character referred 

to as a “preference” value, which indicates the preferred order of delivery if more than one MX 
resource record for a mail exchanger host is found. Each MX resource record must have a cor- 

responding A resource record. RFC 1035 describes the formatting of MX resource records. The 
following is the syntax: 


Owner ttl class MX preference mail exchanger_host 


The following are examples of MX resource records: 


home.org 600 IN MX 10 forest.home.org 
mail 600 IN MX 10 forest.home.org 
home.org 600 IN MX 20 testw2k.home.bobcollier.org 


In the previous examples, home.org is the domain name with forest.home.org as the hostname 
for the mail server and a preference value of 10. Another MX resource record for the domain 
home.org points to a mail server host called testw2k.home.bobcollier.org with a preference value 
of 20. These resource records say that both of these servers will accept mail for any recipient 
that has a domain name of home.org. The DNS resolver will attempt to deliver the message to 
the resource record with the lowest preference value. In this case, it would first attempt deliv- 
ery to forest.home.org. In the event that a connection cannot be made with the host called 
forest, the resolver would look at the results again and select the MX resource record with the 
next lowest value, which would be testw2k.home.bobcollier.org. 


This configuration can be useful to organizations that do not have a dedicated presence on the 
Internet. If an organization needs to receive email but does not have a dedicated connection to 
the Internet, it can have another organization accept mail for it and hold it until the 
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organization is able to connect and retrieve it. There is some coordination and effective com- 
munication that needs to take place between the two organizations, but this can be very useful 
for smaller organizations that cannot afford the dedicated connection. This configuration pre- 
vents mail messages from being nondelivered and returned to the sender, referred to as a non 
delivery report (NDR). 


nslookup can be used to find the host record and TCP/IP address for a mail exchanger host. 
This can be a very useful troubleshooting tool. Figure 8.3 shows how to use nslookup to help 
troubleshoot mail exchanger connectivity issues. 


ul 
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Figure 8.3 Using nslookup to resolve MX resource records to a hostname and TCP/IP 
address. After finding the TCP/IP address, you can check connectivity with the 
host. 


In Figure 8.3, you use the nslookup command to resolve the hostnames for all MX resource 
records for the domain name home.org. The following is the syntax to perform a query for a spe- 
cific resource record type: 


set querytype=mx (notice there are no spaces between querytype=mx) 


Now that the querytype has been set, enter the domain name to resolve (home.org) and receive 
three MX resource records—one for forest .home.org with a preference value of 10, one for 
workhorse.pelicancreek.home.bobcollier.org with a preference value of 20, and one for 
testw2k.home.bobcollier.org with a preference value of 20. 


The highlighted text in Figure 8.3 shows the TCP/IP address of the host forest.home.org that 
you can ping to test for connectivity. If the ping is successful, you know that you can talk to 
the mail exchanger host. 
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We have talked about configuring MX resource records for a mail exchanger host, but what 
happens when the mail exchanger server is behind a firewall like Microsoft’s proxy server? In 
the case where your mail exchanger host is sitting behind a firewall (which is a pretty good 
idea), the MX resource record will have to point to the firewall or proxy server. After the proxy 
server receives the mail message, it will forward the mail to the appropriate mail exchanger 
server. For example, my mail exchanger host is forest.home.org with a TCP/IP address of 
192.168.0.20, and I have a proxy server with a TCP/IP address of 209.184.176.224 on the exter- 
nal interface. 


My DNS entries for the MX and A resource records would need to be configured as follows: 


home.org IN MX 10 mail.home.org 
mail.home.org IN A 209.184.176.224 


Notice that the host resource record for the mail exchanger host is pointing to the proxy 
server. The proxy server will forward the mail message to the appropriate mail exchanger 
server. This scenario assumes that the proxy server and mail exchanger server are on separate 
hosts. 


If both the mail exchanger and proxy server are on the same host, the configuration is some- 
what different. Because both the mail exchanger host and the proxy server are on the same 
host, the mail exchanger host will not use the proxy server. You will need to add and configure 
a static filter on the proxy server. 


To configure the static filter, open the Internet Service Manager by clicking Start, Programs, 
Administrative Tools, Internet Service Manager. After in the Internet Service Manager con- 
sole, perform the following steps: 


1. Select Web Proxy. On the Action menu, click Properties, which will display the Web 
Proxy Service Properties for your_servername dialog box. 


2. Click the Security button, which displays the Security Filter Properties dialog box. 
3. Click the Add button, which displays the Packet Filter Properties dialog box. 


4, Click the Predefined Filter radio button, and then select the SMTP protocol from the 
drop-down box. Then, click OK. 


5. Repeat steps 2 through 4 for POP3 and Identd protocols. 


These steps will allow your mail exchanger host to send and receive mail messages through 
the proxy server. Figure 8.4 shows the Security tab with the SMTP, POP3, and Identd enabled. 
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Figure 8.4 After enabling SMTP, POP3, and Identd through the Web proxy server proper- 
ties, Exchange is able to send and receive mail through the firewall. 


We have described some possible configurations for the MX resource record. Each organization 
will need to look at what its goals are and how much security it needs. There are many possi- 
ble configurations; one solution does not fit every scenario for every organization. 


PTR Resource Records 


Pointer (PTR) resource records are primarily used to support the reverse lookup process. After 
you have created a reverse lookup zone for your site (in-addr.arpa), PTR records allow users to 
resolve IP addresses to hostnames or fully qualified domain names (FQDN). RFC 1035 (page 
18) describes pointer (PTR) resource records in more detail. The following is the syntax for 
PTR resource records: 


a 


Owner ttl class PTR targeted _domain_name 


The following are examples of a PTR resource record: 


20.0.168.192.in-addr.arpa 600 IN PTR _ forest.home.org 
17.0.168.192.in-addr.arpa PTR mustang.pelicancreek.home.bobcollier.org 


In Windows 2000, there are several ways that PTR resource records can be added to a zone: 


E Manually—lf you have hosts or servers that have static IP addresses, you can manually 
add the PTR resource records by using the DNS console. 


E Semiautomatically—When manually adding Host (A) resource records, you can automat- 
ically have the PTR resource record added. To add the PTR record using this method, 
simply check the box next to Create Associated Pointer (PTR) Record. 
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E DHCP Registration—A qualified DHCP Server can register or update PTR resource 
records for DHCP-enabled clients of non-Windows 2000 Microsoft operating systems 
that obtain their IP addresses from the DHCP server. Currently, only Windows 2000 
DHCP servers support this feature. Examples of the non-Windows 2000 DCHP clients 
would be Windows NT 4.0 and earlier, Windows 95/98, and Windows 3.x supporting 
DHCP clients. 


HM Auto Client Registration—Windows 2000 computers that are DHCP-enabled clients can 
dynamically register and update PTR resource records. This happens when they first 
obtain a DHCP lease, if there are changes to their IP address configuration, or when 
they release their DHCP lease. 


PTR resource records are useful when using nslookup. If you are trying to use nslookup and 
receive an error message like “*** Can’t find server name for address 192.168.0.1: Nonexistent 
host/domain,” this suggests that you do not have a reverse lookup zone created or it is config- 
ured incorrectly. PTR resource records are used to resolve the local name server. The resolu- 
tion for this is to create the appropriate reverse lookup zone and manually add the PTR 
resource record for the name server. Try using nslookup again; you will be successful this time. 


PTR resource records also allow hosts to authenticate with servers. Windows 2000 organiza- 
tions will primarily use DNS for name resolution and authentication. If a PTR resource record 
is not created for a host, authentication may fail. Some FTP sites refuse anonymous FTP 
access to hosts that cannot be resolved back to a domain name. Use nslookup to test the PTR 
resource record and resolve both hostname resolution and TCP/IP address resolution (see 
Figure 8.5). 


Figure 8.5 Using nslookup to test forward lookups and reverse lookups for hosts. 
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In Figure 8.5, two host records were tested. Notice that both host records were able to success- 
fully resolve to a TCP/IP address. workhorse successfully resolved to 192.168.0.1, and badhost 
successfully resolved to 192.168.0.18. 


When we tested the reverse lookup process, one record was successful and the other was 
unsuccessful. The reverse lookup for 192.168.0.1 successfully mapped to workhorse. 
pelicancreek.home.bobcollier.org. This suggests the reverse lookup process was successful and 
that an appropriate PTR resource record was present. When trying to resolve 192.168.0.18 to 
badhost.pelicancreek.home.bobcollier.org, we were unsuccessful. This indicates the reverse 
lookup process failed. Either there is no PTR resource record for the host called badhost, or 
there is an incorrect reference to the host. 


In Windows 2000, PTR resource records should not pose a problem because they should 


dynamically update the DNS server. If they do not, the administrator will need to take some 
corrective action. 


SRV Resource Records 


Service location (SRV) resource records are required when using Active Directory to locate 
domain controllers in Windows 2000. SRV resource records allow the use of several servers in 
a single domain environment and the ability to move servers around to different locations, all 
while being transparent to users. An administrator can also designate certain target hosts as 
primary servers for a particular service. There are several SRV records that are automatically 
created during the installation of Active Directory. 


The main SRV records that Active Directory installation creates are for Idap, Kerberos, Global 
Catalog, and domain controllers services. These resource records allow multiple servers that 
are providing similar services to be located with a single query to a DNS server. There are sev- 
eral fields to an SRV record: 


W Name—or domain—Defines the domain name referred to by this resource record. 


W Service—This is a name for the service—there are reserved universal symbolic names 
for well-known services. RFC 1700 defines each of these well-known services along with 
their symbolic name. The (_) is prepended to the service identifier to avoid collisions 
with the DNS labels that occur in nature. The service is case sensitive. 


WE Protocol—This is the transport protocol that the service uses—for example, TCP or UDP. 
Protocols are defined in RFC 1700. _TCP and _UDP are at present the most useful values 
for this field, although any name defined locally or by Assigned Numbers can be used. 
The protocol is case sensitive. 

M 77L—Standard DNS meaning as described in RFC 1035. 


E Class—Standard DNS meaning as described in RFC 1035. SRV resource records occur in 
the IN class. 
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Priority—This is the preference value, similar to that of an MX resource record, defin- 
ing which server resource will be accessed first. This sets the priority of how services 
will be accessed throughout the network. Target hosts that have SRV records with lower 
values will be accessed more frequently than target hosts with higher SRV values. The 
values range from 0-—65,535. For target hosts with the same SRV values, they will be 
accessed in random order. The default value is ø. This is a 16-bit binary integer in net- 
work byte order. 


Weight—This is an additional mechanism that can be used to provide load balancing 
between multiple servers offering the same services. If multiple servers have the same 
priority value, the weight can be configured to make the selection process a bit more 
definitive. For example, I have two servers (testw2k and secondw2k) that offer the _1ldap 
directory service. Both SRV records have a priority of o. If I want users to access 
secondw2k for ldap services more often than testw2k, I would place a value of 1 in the 
weight field on secondw2k and a weight value of 10 on testw2k. This would allow the 
majority of requests to filter through the secondw2k server. For load balancing, the val- 
ues range from 1—65,535. If no load balancing is required, it is best to use a value of ð. 
The default value is 100. 


Port number—Also referred to as port, specifies the entry point for the service on the tar- 
get host. There are well-known ports that should be routinely used, as defined in RFC 
1700. However, any unassigned ports can be used ranging between 0—65,535. 

Host offering the service—Referred to as target host, specifies the DNS host that is 
providing the service. This field indicates the DNS hostname for the host and has to 
have a corresponding A resource record. A . can be used to indicate authoritatively that 
the requested service is not available at this DNS namespace. 


More information about SRV resource records can be found in the Internet-Draft “A DNS RR 
for specifying the location of services (DNS SRV)” (RFC 2782). 


The following is the syntax for an SRV resource record: 


service.protocol.name ttl class SRV preference weight port target 


For example: 


_ldap._tcp.pelicancreek.home.bobcollier.org SRV © 100 389 
workhorse.pelicancreek.home.bobcollier.org 


This SRV resource record defines the LDAP service using TCP on the host called 
workhorse. pelicancreek.home.bobcollier.org. Figure 8.6 shows nslookup resolving an SRV 
resource record. 
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Figure 8.6 This is the proper syntax to resolve an SRV resource record using nslookup; 
notice the information returned in the highlighted text. 


The SRV resource record will become a predominantly used resource record in Windows 2000 
organizations. As the presence of the Internet and intranets grow, so will the use of SRV 
resource records. 


Other Resource Records 


There are several other resource records that are not widely used. Most of the resource records 
that will be mentioned here are classified as “experimental.” Some organizations may find a 
use for some of these resource records. 


HINFO Resource Record 


This is the Host Information (HINFO) resource record and specifies the type of CPU and oper- 
ating system in the cpu_type and os_type fields for the host identified in the owner field. RFC 
1700 specifies “well-known” CPU and operating system codes. RFC 1035 (page 14) describes 
the HINFO resource record. This resource record is not experimental but is not widely used. 


The following is the syntax for an HINFO resource record: 
Owner ttl class HINFO cpu_type os_ type 
The following is an example of an HINFO resource record: 


Old.home.org 600 IN HINFO Intel -386 WIN32 


TXT Resource Record 


This is a Text (TXT) resource record and maps additional description text to the DNS domain 
name specified in the owner field. RFC 1035 (page 20) describes the TXT resource record in 
more detail. This resource record is not experimental but is not widely used. 
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The following is the syntax for a TXT resource record: 
Owner ttl class TXT text_string 
The following is an example of a TXT resource record: 


Forest.home.org 600 IN TXT "This machine is an NT 4.0 FTP and File and print 
server." 3 


WKS Resource Record 


The Well Known Services (WKS) resource record describes the well-known TCP/IP services 
supported by a particular protocol for a specific TCP/IP address. WKS resource records provide 
information for TCP and UDP. LDAP, SMTP, TELNET, and FTP are good examples of “well- 
known” services. RFC 1035 (page 21) describes WKS resource records in more detail. 


The following is the syntax for a WKS resource record: 
Owner ttl class WKS address protocol service_list 
The following is an example of a WKS resource record: 


Home.org 600 IN WKS 192.168.0.20 TCP ( ftp ldap telnet ) 


New and Experimental Resource Records 


There are several resource records that are classified as experimental in RFC 1035 and new 
experimental in RFC 1183. These resource records have not been widely implemented but 
could be of use to some organizations. 


AFSDB Resource Record 


The Andrew File System Data Base (AFSDB) resource record uses DNS to map from a domain 
name to the name of an AFS cell database server. RFC 1183 (page 2) defines this resource 
record in more detail. 


The following is the syntax for the AFSDB resource record: 
Owner ttl class AFSB subtype hostname 
The following is an example of an AFSDB resource record: 
home.org 600 IN AFSB 1 forest.home.org 
The subtype field is a required field that is a 16-bit integer. There are two subtypes: 


HM Subtype 1—Designates that a host is running an AFS version 3.0 Volume Location 
Server for the named AFS cell 
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M Subtype 2—Designates that the host has an authenticated name server holding the cell- 
root directory node for the named DCE/NCA cell 


The hostname field is also a required field. 


_ Description of AFS 
___ The AFS is a registered trademark of Transarc Corporation and is a database similar in function to DNS. That is, it maps the 
| domain name of a cell to authenticated name servers for that cell. 


ISDN Resource Record 


The Integrated Services Digital Network (ISDN) resource record maps a DNS domain name to 
an ISDN telephone number. Telephone numbers should use ITU-T E.163/E.164 international 
telephone numbering standards. RFC 183 (pages 5 and 6) describes ISDN resource record in 
more detail. 


The following is the syntax for an ISDN resource record: 
Owner ttl class ISDN isdn_address sub_address 


The isdn_address identifies the ISDN number for the specified owner and is a required field. 
The sub_address is an optional field. 


The following is an example of an ISDN resource record: 


Forest.home.org 600 IN ISDN 14155552106557161 


MB Resource Record 


The mailbox domain name (MB) resource record is an experimental resource record and maps 
a mailbox hostname to a specified domain mailbox name in the owner field. This resource 
record must have an accompanying A resource record and a valid mailbox that accepts mail for 
the specified owner. RFC 1035 (page 14) defines MB resource records in more detail. 


The following is the syntax for an MB resource record: 
Owner ttl class MB mailbox_hostname 
The following is an example of an MB resource record: 


bob.home.org 600 IN MB mailsrv.home.org 
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MG Resource Record 


The mail group (MG) resource record is used to add domain mailboxes to the domain mailing 
group specified in the owner field of the resource record. Each mailbox must have a correspon- 
ding valid MB resource record that has already been created. RFC 1035 (page 16) defines MG 
resource records in more detail. 


The following is the syntax for the MG resource record: 
Owner ttl class MG mailbox_name 

The following is an example of an MG resource record: 
Admin. home.org 600 IN MG peter.home.org 


George.home.org 
Andrew. home.org 


MINFO Resource Record 


The mailbox mail list information (MINFO) resource record specifies a domain mailbox 
responsible person that maintains a mailing list of the box specified in the owner field and can 
specify a domain mailbox that receives any error messages related to this mailing list. The two 
values are responsible mailbox and error_mailbox. RFC 1035 (page 16) defines the MINFO 
resource record in more detail. 


The following is the syntax for the MINFO resource record: 
Owner ttl class MINFO responsible mailbox error_mailbox 
The following is an example of an MINFO resource record: 


Admin. home.org 600 IN MINFO bob.home.org bob.home.org 


MR Resource Record 


The mailbox renamed (MR) resource record specifies a new domain mailbox name for the 
entry in the owner field. This is useful as a forwarding mechanism when a domain mailbox is 
renamed. RFC 1035 (page 17) describes the MR resource record in more detail. 


The following is the syntax for an MR resource record: 
Owner ttl class MR new_mailbox 
The following is an example of an MR resource record: 


Rcollier.home.org 600 IN MR bcollier.home.org 


Other Resource Records 171 


RP Resource Record 


The responsible person (RP) resource record specifies the domain mailbox name for a mailbox 
of the responsible person that is specified in the owner field. A reference to a TXT file is also 
used with this resource record. After an RP resource record is used in a DNS query, subse- 
quent queries will be used to retrieve the associated text (TXT) resource record information. 
RFC 1183 (pages 3 and 4) describes the RP resource record in more detail. 


The following is the syntax for an RP resource record: 
Owner ttl class RP mailbox_name text_record_name 


The text_record_name is the name of the text file that contains information about the responsi- 
ble person. 


The following is an example of an RP resource record with the associated TT resource record: 


home.org 600 IN RP bob.home.org rp-info.home.org 
rp-info 600 IN TXT "Bob Collier, (210)555-5555" 


RT Resource Record 


The Route Through (RT) resource record provides a routing host for an internal host that does 
not have direct access to a wide area connection. This resource record is very similar to an MX 
resource record. RFC 1183 (pages 7 and 8) describes the RT resource record in more detail. 


The following is the syntax for an RT resource record: 
Owner ttl class RT preference intermediate_host 


The following is an example of an RT resource record: 


home.org 600 IN RT 10 lan-router.home.org 
600 IN RT 20 wan-router.home.org 


This is specifying a route to the local area network and the wide area network. 


X.25 Resource Record 


The X.25 (X.25) resource record maps a Public Switched Data Network (PSDN) address num- 
ber to a DNS domain name specified in the owner field. The PSDN address numbers should 
follow the X.121 international numbering plan. RFC 1183 (page 5) describes the X.25 resource 
record in more detail. 


The following is the syntax for an X.25 resource record: 


Owner ttl class X.25 psdn_number 
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The following is an example of an X.25 resource record: 
Home.org 600 IN X.25 52204455506 


This chapter has defined several resource records and their uses. The important concept to 
remember here is that not all resource records need to be used by all organizations. The infor- 
mation in this chapter was designed to provide basic information about each of the resource 
records to include syntax and basic usage. 


USING WINDOWS 2000 
DNS As A LOCATOR 
SERVICE 


DNS replaces the Windows Internet Name Service (WINS) as a Windows 
2000 network’s service locator for Windows 2000 networks by incorporating 
Service Resource Records (SRV) into zones, which can be used to identify 
network services. In comparison, with Windows NT networking, the WINS 
service provides the same capability using NetBIOS names, in which the 
16th byte of the computer name identifies the networking service the server 
is advertising. 


To better understand the role of DNS and SRV resource records in a 
Windows 2000 network, you must have an understanding of Windows 2000 
networking. If you are familiar with Windows NT networking and the 
WINS service, you can compare the use of the DNS service in Windows 
2000 networking with the use of the WINS service in Windows NT 
networking. 


Windows 2000 Networking 


To understand how DNS SRV resource records work, and what zones are 
created as a result of implementing Active Directory, you must be familiar 
with some Windows 2000 networking terms and the networking structure. 
Windows 2000 networking supports two types of networking structures: 
workgroups for peer-to-peer networking, and domains for client/server 
networking. 
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Workgroup 


A workgroup is a peer-to-peer network, in which each computer on the network is its own 
administrative and security boundary. Each Windows NT or Windows 2000 computer has 
locally stored user accounts that provide the rights necessary to log on to the computer and 
access local resources. As shown in Figure 9.1, if Useri on Computer1 wants to gain access to 
a printer on Computerd, the user would have to have an account on Computerd. 


Computer 2 


Computer 4 


WORKGROUP 


Figure 9.1 A workgroup is a peer-to-peer networking environment, in which each computer 
is its own security and administrative boundary, with a locally stored database of 
user accounts. 


Resources can be accessed from the network, but to gain access, you must have rights that are 
provided by the computer you are attempting to access. This can be accomplished by 


E Having a user account on the computer you are attempting to access from the network. 


W Configuring the computer you are attempting to access to allow access to nonauthenti- 
cated users. 


For each computer you access, either locally or across the network, you must have a valid 
username and password. With workgroups, there is no Active Directory and there are not any 
domain controllers, so you do not need the DNS service to locate network services. DNS is 
used in only the traditional sense to locate computers on the intranet or Internet. 
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Domain 


A Windows networking domain is a client/server networking structure, in which a server on 
the network called a domain controller stores the computer and user accounts for all the com- 
puters and users that are members of the domain. So, if Computer1 needs to gain access to a 
printer on Computer2, Userl on Computer1 is authenticated by Domain Controllerl and pro- 
vided the information needed to create an access token. User1 provides the access token when 
attempting to access the printer on Computer2 for authentication. Figure 9.2 shows the 
domain-networking model. 


_ The Triangle 
__ When reviewing online documentation or Windows 2000 reference materials, a Windows 2000 domain is represented by a 
= triangle. 


Computer 1 Computer 2 


Computer 4 Domain 


Controller 1 


DOMAIN 


Figure 9.2 A domain is a client/server-networking environment, in which the domain is the 
security and administrative boundary, with the database of user and computer 
accounts being stored on a domain controller. 


Using the domain model of networking provides centralized administrative control over all the 
network resources and provides the end user with one username and password that is used to 
access any resources available in the domain. As you can tell from the description, this is not 
the same as a domain on the Internet. 


In a domain, each Windows NT or Windows 2000 computer has an account in the domain, just 
as a user has an account. Therefore, both the computer and the user are domain clients. When 
the computer boots, or a user logs on to the domain, a domain controller is contacted to 
authenticate the client computer or user account and provide the information needed to build 
an access token. 
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' The access token is presented whenever the user or computer attempts to access a resource 
on the local computer or network. To locate a domain controller, the client computer sends a 
query to the DNS server configured in the TCP/IP properties on the client computer, request- 
ing the IP address of a domain controller for the domain. 


Domain Networking Architecture 


As stated previously, with Windows 2000 networking, domains are administrative and security 
boundaries. The Windows 2000 network domain structure appears to follow the same naming 
as the Internet’s DNS namespace, where there can be parent and child domains that form a 
domain tree, and combine to create a single network. Although the names can appear to be the 
same, the Lightweight Directory Access Protocol (LDAP) is used to navigate the Windows 2000 
Active Directory structure, whereas domain names are used to navigate the domain name- 
space. The LDAP information is maintained in Active Directory, while they are located by a 
DNS server. Therefore, DNS queries are used to resolve queries for Active Directory objects in 
the domain. 


A domain tree (shown in Figure 9.3) is a multidomain network structure that has a contiguous 
namespace and is part of the same network. For instance: 


M 501redtab.com can be the parent domain for engineering.501redtab.com. 
E Engineering.501redtab.com would then be a child domain of 501redtab.com. 


@ Both could be part of the same network, sharing some common information and the 
capability to access each other’s network resources. 


com 


WINDOWS 2000 
DOMAIN TREE 


501REDTAB.com 
WINDOWS 2000 DOMAIN 


NGINEERING.501REDTAB.com 
WINDOWS 2000 DOMAIN 


Figure 9.3 50lredtab.com and engineering.501.redtab.com belong to the same Windows 
2000 network, forming a domain tree. 
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Domain trees can be grouped together into forests. A forest is a group of domain trees that 
share a common schema, object index, and has two-way transitive trusts between the domains. 
This allows users to locate and gain access to resources throughout the forest. Figure 9.4 
shows the communications used to locate a network resource on a Windows 2000 network. 
Userl on a computer named Client1 needs to print to PrinterA. 


1. Client1 queries a DNS server to find the IP address of an index server for the forest. 


2. Client1 queries IndexServerl (a computer that is advertising the forest index service) 
for a printer object named PrinterA and discovers the printer is managed by 
PrintServerA. 


3. After the IP address for PrintServerA is resolved, Client1 can print to the PrinterA. 


501redtab.COM 
and 
TOGODINER.com 
are part of 4 
the same Windows 


2000 Domain 
501REDTAB.com 


WINDOWS 2000 
DOMAIN 


TOGODINER.com 
WINDOWS 2000 
DOMAIN 


Index Server 1 Print Wr DNS Ri 
is part of PrinterA Servera `x Server 


501REDTAB.com | “O. . C) 


Client 1 
Computer is part of 
TOGODINER.com 


Figure 9.4 To locate a server with a particular resource, a computer queries a DNS server 
for an index server that provides the information needed to locate a print server. 
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The objects that can be created in a Windows 2000 network are defined in the network’s 
schema. A schema is the network’s blueprint, providing information about what objects are 
valid in the forest, and what attributes can be defined for each object. 


The object index is stored in a global catalog, which is an index of all of the objects in the for- 
est. The global catalog database has a record for each object in the forest, but that record does 
not store all the data for each attribute defined for every object. 


The two-way trust provides an authentication path between all of the domains in a forest. 
This allows users to gain access to resources in all the domains in a forest. The trusts are cre- 
ated automatically between the domains as they are added to the forest. The authentication 
path flows up and down the domain tree. Because the trusts are two-way, any user in any 
domain can be authenticated in any other domain, as long as they are both in the same forest. 


DNS in a Windows 2000 Networking Environment 


When you run the Active Directory Wizard to create a domain controller, the domain controller 
contacts a DNS server, which you specify, to populate the DNS zone with information about 
the names and services the domain controller will offer to your Windows 2000 network. Later, 
the network clients use this to locate domain controllers for authentication, global catalog 
servers to discover other objects in the network, name resolution for other computers on the 
network, and so on. 


For example, when a user boots a computer running Windows 2000, part of the boot process is 
to locate a domain controller that can authenticate the computer account in the domain, and 
then locate a domain controller that can authenticate the user account in the domain when 
the user attempts to log on. The authentication process can vary greatly, depending on the net- 
work structure and configuration. The basic sequence of steps is as follows (see Figure 9.5): 


æE When a computer is started, it contacts the DNS server configured in its TCP/IP proper- 
ties, and queries the DNS server for a domain controller that can authenticate the com- 
puter account. This is accomplished by querying for an SRV resource record for the 
domain. 


@ The computer contacts the domain controller for authentication. 


E The user account might follow the same process to be authenticated, but, if the user is a 
member of the same domain as the computer, the user can contact the domain controller 
using the resolution information received during the computer authentication process. 


In a Windows 2000 network, you create a domain controller for a Windows 2000 domain by 
installing Active Directory. The DNS server that you will use to support Active Directory can 
be configured before you install Active Directory, or as part of the Active Directory setup 
process. 
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Domain 
Controller 


Figure 9.5 When a computer is booted, it will seek to authenticate the computer and user 
account. 


You create a domain controller by running the dcpromo.exe utility rather than defining the 
computer as a domain controller as part of the installation of the operating system. The 
dcpromo.exe command starts the Active Directory Installation Wizard. During the wizard, you 
must select 


@ Whether the new domain controller will be a domain controller for a new domain or a 
replica domain controller for an existing domain. 


@ Ifthe domain controller is for a new domain, you must select whether the domain is 
part of an existing domain tree, or is in a new domain tree. 


You also must provide the address of a DNS server that will support the Active Directory, or 
allow the Active Directory Wizard to install and configure the DNS service to support the 
Active Directory. 


If you allow the Active Directory Installation Wizard to configure the DNS service, the DNS 
service is configured to allow automatic updating; therefore, the update to the zone informa- 
tion for computers and services being advertised in a Windows 2000 network are done auto- 
matically. If not, you will need to enable dynamic updates on the DNS service that will 
support the domain. 
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Dynamic Update in Windows 2000 


Windows 2000 networks use DNS to locate network services, as well as locate other computers 
on a network. Because DHCP is used to provide computers with an IP address lease, keeping 
the zone data in a DNS server up to date could be too costly in administrative overhead; there- 
fore, dynamic update should be used to keep zone information current. 


Dynamic DNS and Dynamic Update were introduced into the RFC standard track to provide a 
mechanism that allows computers to update DNS zone information as part of the operating 
system’s standard operations. Dynamic DNS is described in RFC 2782 and Dynamic Update is 
described in RFC 2136. Windows 2000 also supports Secure Dynamic Update as described in 
the IETF Internet-Draft “GSS Algorithm for TSIG (GSS-TSIG).” 


With Dynamic Update, when a Windows 2000 client computer is started, part of the startup 
process is to contact a DNS server and update its resource records. If the client computer 
receives an address from a DHCP server, the DHCP server can be configured to update the 
DNS zone information on behalf of the client computer. 


How Dynamic Update Works 


The two main resource records that a client computer updates in a DNS zone are the forward 
and reverse lookup resource records. That is, the A record and the PTR record. The other 
records that are updated on a Windows 2000 computer are the SRV records. The SRV records 
are used to help advertise and locate services available on the network. 


When a client is started (when the boot process occurs), part of the process is to locate the 
name server that is authoritative for its zone, and update the A and PTR resource records. The 
service on the client computer that performs the update is the DHCP client service. The DNS 
server can be configured to allow either secured or nonsecured updates. There are several con- 
figuration options for the update process you can configure that determine which computer 
will perform the update, and whether the update will be secured or nonsecured. 


Figure 9.6 shows the update process that is used if the client computer is performing the 
update, and the update is configured on the DNS server to be secured. In this example, the 
server is the domain controller and authoritative name server for 501redtab.com. The follow- 
ing sequence is used: 


1. ClientA (the client computer) queries for the SOA of the zone that maintains its A and 
PTR records. In this example, ClientA queries its local name server for the authoritative 
name server for the 501retab.com zone, which, in this case, is also the authoritative 
name server for the 501redtab.com zone. The name server responds with the response to 
the query. If the authoritative name server were not the local name server, the client 
computer would then query the authoritative name server to verify that it is authorita- 
tive for the zone. 
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2. ClientA then attempts to perform a nonsecured update of the zone information for the 
501redtab.com zone. The DNS name server is configured to allow only secured zone 
updates, so the nonsecured update is refused. If the DNS name server were configured 
to allow nonsecured updates, the server would update the zone information. 


3. ClientA and the DNS name server negotiate a security context and use TKEY resource 
records as the vehicle to pass security tokens. TKEY resource records are described in 
the IETF Internet-Draft “Secret Key Establishment for DNS (TKEY RR).” The Windows 
2000 client and server propose Kerberos as the underlying security mechanism, and 
then verify each other’s identity. This will be used to verify transaction signatures 
between the two computers. 


4, ClientA sends the signed dynamic update request to the name server using a TSIG 
resource record. TSIG resource records are described in the IETF Internet-Draft “Secret 
Key Transaction Signatures for DNS (TSIG).” The update is made to the DNS zone and 
to Active Directory if all prerequisites are met and the client has permission to make the 
update. The server sends a response indicating whether the update is allowed or not. 


Find Name Server Authoritative 


for 501REDTAB.com Name 
Server 


CLIENTA.501REDTAB.com 

Sanne ee 
Attempt Non-secure Update (2) 

pee ne e 


TKEY Negotiation (3) 


wn n mee ea a 
Update Zone Using TSIG ©) 
Me 


Figure 9.6 When a client computer starts, the computer locates the authoritative name 
server for its zone, negotiates an update, and then sends the update information. 


The new opcode used to perform the update is called Update. The update message can be sent 
to a DNS server to add or delete records, if a set of criteria is met. 


» Nonsecured Updates 
4 Nonsecured dynamic updates are defined in RFC 2136. With nonsecured updates, any computer can remove, modify, or add 
< resource records to a DNS zone. 


The owner of the resource record that is updated is the client computer, and can be deleted 
only by the client computer. If the DHCP server is configured to perform the update (A and 
PTR resource records) on behalf of the client computer, and is a member of the DNS Update 
Proxy group, the record is owned by that group, which has no associated security. This pro- 
vides a vehicle to remove stale resource records. 
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With the use of the DNS Proxy Update group, if there are multiple DHCP servers, and one 
server fails, any DHCP server can update the record. If a Windows 2000 computer should 
register an A or PTR resource record of the same name, the computer can delete the record 
register by the DHCP server and register its own records. 


SRV Resource Records 


The SRV resource record is described in RFC 2782, which makes obsolete RFC 2052. The 
notion behind these records is to provide administrators with a way to configure a network 
service on several servers, balancing workload across all the servers and minimizing network 
traffic. The format of the SRV resource record (see Figure 9.7) is as follows: 


Preference 


ifs 4 _kerberos SRY [0][100][88] texas.SO1redtab.com. 
H G-E Forward Lookup Zones e ldap SRY  [0][100][389] texas.501redtab.com. 
| | S- Sotredtab.com i 

i Q 


-Ga tcp 


| 8 {23 domains E: 
| | E e9f9d731-cece-42 


Service Type Weight Target 


Figure 9.7 The SRV Resource Record aids administrators in configuring a network service 
across multiple servers. 


E Service—The service is listed first under the Name column. In the case of Windows 
2000, _kerberos and _ldap protocols are used for authentication and location of Active 
Directory objects, respectively. 


E Type—tThe type of resource record is SRV. For most other currently used resource 
records, the type is IN. IANA has assigned the SRV resource record the RR type value 
of 33. 

E Priority—The priority (or preference) determines the order in which the client com- 


puter will attempt to contact servers that are providing a service. The client computer 
should attempt to contact the server with the lowest priority number first. For instance, 
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if the response to a query for a server providing domain controller services yields the IP 
address of two servers, one with a priority of 1, and the other a priority of 0, the client 
computer will attempt to contact the server listed with the priority of 0. 


E Weight—The weight determines the order in which the DNS server should list servers 
that can provide a network service. The server with the highest weight is listed first, 
and therefore should have the highest probability of being selected. For instance, if a 
DNS name server has a list of two servers providing domain controller services, one 
with a weight of 0, and the other with a weight of 1, the name server will list the server 
with the priority of 1 first and should be selected. 


E Port—tThe port is the port number used with this resource record. Valid ports are 
listed in RFC 1700. In this case, the record is contained in the _tcp folder; therefore, 
the _kerberos record uses TCP port 88 and the _Idap record uses TCP port 389. 


E Target—tThe target is the fully qualified domain name of a server providing the service 
and cannot be an alias. The target must have at least one or more address records (A or 
AAAA) listed. For instance, texas.501lredtab.com would have to have at least one IP 
address that it could be resolved to. If there were more than one address, the priority 
and weight would be used to determine which of the servers was contacted. 


To view the SRV resource records for a domain, from Administrative Tools, open DNS, and 
then expand the view on any Windows 2000 networking domain zone. Windows 2000 is fully 
RFC 2782 compliant. For more information, refer to the RFC or online help in Windows 2000. 


Updating Zone Information 


Zone information can be updated automatically by the client computer or by the DHCP server 
on behalf of the client computer. You also can manually add resource records to a zone using 
the DNS management tool or by modifying the DNS zone file directly, unless the zone is an 
Active Directory—integrated zone. If you are at the client computer, you can reregister the A 
and PTR resource records using the ipconfig command-line utility using the following syntax: 


C:\>ipconfig /registerDNS 


If you want to refresh the SRV resource records, you must stop and restart the Net Logon 
service. To stop and then start the Net Logon service from the command line, use the following 
syntax: 


C:\>net stop netlogon 
C:\>net start netlogon 


A message will appear indicating that the service is stopping and when complete, a message 
will appear indicating it has stopped successfully. When the Net Logon service is started, a 
message will appear indicating the service is starting, and when completed, will provide a 
message indicating the service started successfully. 


MAINTAINING DNS IN 
WINDOWS 2000 


Although dynamic updates allow client computers to automatically update 
zone database information, there are tasks you will be required to perform 
to keep your DNS server operating properly. This chapter will cover some of 
those tasks. 


Securing DNS 


You have the ability to secure the DNS service in Windows 2000 in two dif- 
ferent ways. You can force the client computer to use secured dynamic 
updates, and you can encrypt the zone transfers between name servers. 
Both require that the zones on the name server be changed to Active 
Directory—integrated zones. 


By changing the zone to Active Directory—integrated zones, the resource 
records become part of the Active Directory, and the client computer must 
be authenticated and authorized before the objects can be updated. The 
zone transfer that keeps zone information synchronized is performed as 
part of the Active Directory synchronization process. 


Secure Dynamic Update 


Secure Dynamic Update will not allow the client computer to update the 
zone information on a DNS name server unless that client forms a secured 
connection first. 
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The client computer can be configured to attempt to update the zone information in three dif- 
ferent ways: secure update only, nonsecure update only, or attempt nonsecure and if required, 
perform a secure update. The name server can be configured in three different ways, also: 
allow updates, not allow updates, allow only secure updates. 


Note 
 Atthe writing of this book, only Windows 2000 client computers can be configured for secure dynamic updates. 


Client Settings 


On Windows 2000 client computers, you can configure the way the client computer will 
attempt to update the zone information. If the client computer has different settings from the 
name server, the client computer must be able to perform the update as configured on the 
server. By modifying the Registry, you can configure the TCP/IP properties so that the client 
computer attempts to perform updates in one of three ways: 


E Nonsecure updates only—If the client computer is configured to perform nonsecured 
updates only, the client computer will attempt to update the zone information on the 
name server without using an underlying secured session. If this fails, the client will not 
update the zone information. 


W Secured updates only—lIf the client computer is configured to perform secured updates 
only, the client computer will establish a Kerberos session with the name server that is 
authoritative for its zone, and then update the zone information. 


E Both—tThe client will attempt to perform the update without first establishing a secured 
channel, and then, if the update is refused, will authenticate using Kerberos, and then 
update the zone information. This is the default setting for the Windows 2000 operating 
system. 


The Registry setting (see Figure 10.1) that controls this behavior is HKEY_LOCAL_ 
MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters. The value you config- 
ure is UpdateSecurityLevel, which must be added if you are changing from the default setting. 
The valid settings are 


@ O0—Nonsecure; then secure update if needed 
mM i6—Nonsecure updates only 
E 256—Secured updates only 
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Figure 10.1 To configure how the client computer attempts to update the zone information 
on the name server, configure the UpdateSecurityLevel setting in the Registry 
on the client computer. 


Server Settings 


On the name server, you configure what types of updates are allowed using the DNS manage- 
ment tool. This setting should be configured for each zone you create. You can configure the 
zone to 


E Allow dynamic updates—This setting configures the zone to accept dynamic updates 
from client computers. 


@ Do not allow dynamic updates—This setting configures the zone to refuse zone updates. 


W Allow only secure updates—tThis setting will cause the zone to refuse the update unless 
secured using Kerberos. 


To configure the settings for the type of dynamic update allowed: 


1. From Administrative Tools, open DNS. 
2. Right-click the zone you want to configure, and then click Properties. 


3. On the zone’s properties page, under General, click Allow Dynamic Updates?, and then 
select the type of update you want to allow (see Figure 10.2). 
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Figure 10.2 To configure the types of updates that are allowed for a zone, right-click the 
zone and under the General tab, configure the desired settings. 


You can select yes or no to allow or not allow dynamic updates. If you are configuring an 
Active Directory—integrated zone, you also will have the option to allow only secure updates. 


With Active Directory—integrated zones, the A and PTR resource records are part of the Active 
Directory, and are owned by the computer that is performing the update. The only groups 

or users besides the computer that can update or remove the resource records for that com- 
puter are 


HM DNSAdmins 
Domain Admins 
Enterprise Admins 


Enterprise Domain Controllers 


The Administrators local group does have Read and Write permission for the resource records, 
but does not have the Full Control permission (see Figure 10.3). 


Note 

if a DHCP server is configured to update the resource records on behalf of the client and the DHCP server is a member of the 
_ DnsUpdateProxy group, the first client computer to attempt to refresh the update will become owner of the record. If the DHCP 

«$ server is also a domain controller, it can replace existing resource records. 
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Figure 10.3 To view the security settings for individual resource records, right-click the 
record and click Properties. 


Day-to-Day Tasks 


The day-to-day tasks you perform will depend on whether you run a proactive or reactive 
shop. The DNS service that comes with Windows 2000 is self-maintaining, much as a self- 
cleaning oven cleans itself. That is to say, if everything is working properly, the client comput- 
ers will update their A and PTR resource records correctly, and the DNS server will respond to 
queries providing back the needed response. However, you will still be required to perform 
some administrative tasks to keep the DNS service operating properly. 


Some of the tasks you will need to perform include reviewing the DNS log files, cleaning up 
orphan resource records, using Performance Monitor to evaluate the DNS server, and planning 
for disaster recovery. 


Viewing the Event Log for DNS 


One of the best preventative tools available to the DNS administrator is the DNS server event 
log. The event log records three different severity levels of events: 


E Information—tThis type of event does not indicate a problem, but provides information 
of significant events that have occurred on your DNS server. For instance, when the 
DNS service is stopped and started, an Information event is recorded in the event log. 


HM Warning—tThis type of event does not indicate an immediate problem, but does require 
that the DNS administrator review the event and take any necessary action. For 
instance, when a server running the DNS service does not have a domain name config- 
ured (only a hostname is configured), a Warning event will be recorded in the event log. 


190 Chapter 10 Maintaining DNS in Windows 2000 


E Error—this type of event indicates an error that requires immediate attention from the 
DNS administrator. For instance, when a DNS name server cannot update the zone 
information for an Active Directory—integrated zone, an Error event is added to the 
event log. 


To view the Event logs for DNS, choose From Administrative Tools, and then click Event 
Viewer. Click on DNS Server to view the DNS server event log. 


You also can configure logging for the DNS service. These are typical DNS events that you 
elect to record in a log file. This log can contain information that is useful for troubleshooting 
your DNS server. 


To configure the events (Figure 10.4) that will be recorded in the DNS event log: 


1. From Administrative Tools, click DNS. 


2. Inthe DNS tool console tree, verify that the server you want to configure is highlighted, 
and then from the Action menu, click Properties. 


3. In the Properties dialog box, under the Logging tab (see Figure 10.4), select the events 
you want to log. The log file is stored in a file named systemroot\system32\Dns\Dns.1log. 


Full packets 
Wi Wiite through 


Figure 10.4 You can configure the events you want to log using the DNS Manager adminis- 
trative tool. 
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Cleaning Up Orphan Entries 


Orphan entries are resource records that are no longer needed, but are still in the zone data- 
base. For instance, if a computer is connected to the network and, through dynamic update, 
has added resource records to a zone, then if the computer fails but is not replaced, the 
resource record might not be deleted. 


You can configure the DNS service in Windows 2000 to scavenge resource records automati- 
cally or manually by using the DNS management tool, or you can use the Dnscmd.exe utility. 


Configuring Automatic Scavenging 


Automatic scavenging will automatically remove resource records that have not been refreshed 
by the client computer for an amount of time that you specify. By default, scavenging is dis- 
abled. You can configure automatic scavenging to affect 


W A server 
E Azone 
W A resource record 


To configure automatic scavenging for all zones on a server: 


1. From Administrative Tools, click DNS. 


2. Click to highlight the server you want to configure, and then from the Action menu, 
click Set Aging/Scavenging for all zones. 


3. To enable scavenging, place a check in the Scavenge Stale Resource Records check box 
(see Figure 10.5). 
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Figure 10.5 The Server Aging/Scavenging Properties window allows for configuration of 
scavenging for zones. 
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There are two options to set when configuring scavenging: 


E No-refresh Interval—When you enable scavenging, resource records that have not 
been refreshed since the time listed in the No-Refresh Interval box will be removed from 
the zone database. 


M@ Refresh Interval—When you enable scavenging, this is the minimum time that can 
elapse before a resource record can be scavenged. 


After you enable scavenging, any new resource records that you create will be affected. Ina 
standard primary zone, any resource records that were created before you configured scaveng- 
ing will not be affected. 


You also can scavenge individual zones (Figure 10.6). To scavenge a zone: 


1. From Administrative Tools, open DNS, right-click on the desired zone, and then click 
Properties. 


2. From the Properties window for the zone, under the General tab, click the Aging button. 


3. Set the desired parameters for scavenging (see Figure 10.6). The window that appears is 
similar to the dialog box seen when configuring scavenging for the server. 
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Figure 10.6 The Zone Aging/Scavenging Properties window operates in nearly the same 
manner as the Server properties window. 


To configure scavenging on individual resource records, right-click the resource record you 
want to configure and then click Properties. 


E For NS and SOA resource records, under the General tab (see Figure 10.7), click the 
Aging button and then configure as you would the zone or server. 

E For Aand PTR resource records, click the check box beside Delete This Record When It 
Becomes Stale. This is the only option you have for configuring A and PTR resource 
records. 
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Figure 10.7 Scavenging settings can be configured for resource records through the resource 
record’s property page. 


When planning to enable scavenging, remember that resource records in a standard primary 
zone that are created before you enable scavenging will not be affected. To configure those 
records to be affected, you must either delete and create new resource records, or use the 
Dnscmd.exe utility with the AgeAllRecords switch. This is explained in detail in Chapter 12, 
“Securing and Troubleshooting DNS Communications.” 


Performance Monitor 


The Performance tool that comes with Windows 2000 can be used to monitor many of the sys- 
tem’s hardware and software resources. After you install the DNS service on a computer run- 
ning Windows 2000 Server, counters are added to the Performance Monitor tool that enable 
you to monitor DNS operations. 


When you install Windows 2000, the Performance tool is installed automatically. When you 
install the DNS service, a DNS object is added to the list of available objects you can monitor 
in Performance. 


When using the Performance tool, there are objects, counters, and instances: 


E Object—An object is a major subsystem of the system. This can be either a hardware- 
or software-based subsystem. For instance, the Processor and DNS are objects that can 
be measured. 


E Counter—A counter is a specific measurable component of an object, and is specific to 
that object. For instance, the percentage of processor time utilized is a counter for the 
processor object. 
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Æ Instance—An instance is each occurrence of an object there is in a system. For 
instance, if there are two processors installed in a system, they are both processor 
objects, but each processor is its own instance: instance 0 and instance 1. There also 
would be a total instance that combines both instances together. 


Each of the system objects has several built-in counters that can be used to view system per- 
formance either in real-time, or by logging the information and reviewing it later. If there are 
multiple instances of a particular object, you can choose to monitor one or all of the instances 
for each object. For instance, there is an object named Processor that enables you to monitor 
counters for the percentage of processor time used, and others for the percentage of time used 
for the User level and for the Kernel level. If you had multiple processors installed in the sys- 
tem, each processor would have its own instance, so that you could measure the performance 
of each processor. 


DNS Counters 


Using the DNS object, you can measure the DNS server’s performance either in real-time, or 
by logging the information for viewing later. If you log the data, it can be archived and them 
compared with later versions of logged data to help track usage. This can be particularly use- 
ful when planning for additional DNS servers. Some of the counters you can view include 


Zone transfer information, including AXFR, IXFR, and zone transfer totals statistics 


Memory usage, including memory used for caching, NBT memory, and database node 
memory 


Dynamic Update statistics 
Notify statistics 

Recursive statistics 

Secure Update statistics 
TCP and UPD statistics 
WINS interaction statistics 
Totals for the DNS service 


A full list of the counters with explanations of each can be viewed with the Performance tool. 
To open Performance and view the counters with explanations of each: 


1. From Administrative Tools, click Performance. 
In the detail pane of Performance, click the plus (+) icon. 


3. Inthe Add Counters window (see Figure 10.8), under Performance object, select DNS, 
and then click the Explain button. 
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Figure 10.8 With Performance, you can monitor the DNS object, which has several counters 


that enable you to track the performance of your DNS server. 


An explanation of each counter will appear as you click the counter. 


Viewing Real-Time Data 


To view real-time DNS performance data: 


1. 


From Administrative Tools, click Performance. 


In the console tree, verify that System Monitor is highlighted, and then in the details 
pane, click the Plus (+) icon. This will open the Add Counters window. 


In the Add Counters page, under Performance objects, select DNS. This option is avail- 
able only if you have installed the DNS service. 


Under Select Counters, select the counters you want to monitor, and then click Add. 
When you are done selecting counters, click the Close button to return to the graph page 
(see Figure 10.9). By using the icons buttons along the top of the detail pane, you can 
view the data in bar chart form or graph form. 


Logging Data 


As stated earlier in the chapter, you can capture data in a log file and then view it later using 
the Performance tool. To log DNS performance data: 


1. 
2. 


From Administrative Tools, click Performance. 


In the console tree, expand Performance Logs and Alerts, right-click Counter Logs, and 
then click New Log Settings. 


In the New Log Settings dialog box, type the name you want the log file to be called. For 
instance, you could name the log file DNS 5 5 2000. 
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Figure 10.9 Viewing real-time DNS counter data using the Performance tool. 


4, In the properties page for the log file, under the General tab, click Add to add the coun- 


ters you want to log. When you have added all the counters you want to log, close the 
Add Counters dialog box. 


5. On the log file properties page, under the Log Files tab (see Figure 10.10), you can con- 
figure several options, including the name and location the log file will be stored in, the 
file type that will be created, and the maximum size of the log file. 


Figure 10.10 Under the Log Files tab, you can configure the name, maximum size, and 
storage location of a log file. You can also set the file type to binary, binary 
circular, or a delimited text file. 
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6. After you have configured the desired settings, click OK. The log file will appear in the 
details pane. To stop logging, right-click the log file, and click Stop. 


You can view the data recorded in the log file using the System Monitor portion of the 
Performance tool. To view the information stored in the log file: 


1. In the console tree of Performance, click System Monitor. 
In the details pane, right-click the View Current Activity icon, and then click Properties. 


3. In the System Monitor Properties page, under the Source tab (see Figure 10.11), click 
Log file, and then provide the path to the log file you want to view. 


Figure 10.11 Viewing logged data enables you to capture data for archiving purposes, and 
then view the data later. 


4. Select the time range you want to view, and then, under the data tab, select the counters 
you want to view. Click OK to view the data. 


There are several options for displaying the information using the System Monitor. You can 
view the data on the DNS server where the information was gathered, or you can view the 
data on any computer running Windows 2000. 


You also can schedule times when the logging will start and stop, and save the data in a 
delimited text file, for easy manipulation from a spreadsheet or database program. — 
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Planning for Disaster Recovery 


As important as planning for success is, you must also plan for disaster recovery. Some of the 
items to consider when planning your DNS deployment include the following: 


Configure your DNS servers correctly. This sounds obvious, but be sure to configure the 
SOA record correctly so that you will receive email if your DNS server is not operating 
properly. Be sure to configure multiple servers for each zone. 


Use Active Directory[dn]integrated zones if you have implemented Active Directory. 
Active Directory—integrated zones provide several advantages over standard primary 
and secondary zones. Active Directory—integrated zones are multiple master zones. 
Because the zone is part of Active Directory, any domain controller with DNS installed 
can be used to maintain the zone information. Also, the information is more secure, and 
you can configure secure updates to the zone information. Last, the zone replication is 
more efficient with large zones, because Active Directory propagates changes on a per- 
property basis. 


Enable scavenging of stale resource records. Configured properly, enabling scavenging 
will keep your zone databases free of resource records that are no longer valid. Of 
course, as with any automated system, this will still require that the DNS administrator 
view the log files associated with DNS. 


If you are using standard zones, place the standard primary zone on the most reliable 
server you have. If the server hosting the primary zone fails, the servers hosting second- 
ary copies of the zone database will stop responding to queries when the information can 
no longer be refreshed. The settings on the primary name server determine how long the 
secondary name server will consider the information stored in their copy of the zone 
database valid. 


If you are in an environment with Windows 9x and Windows NT computers, and you are 
currently using WINS for name resolution, configure the DNS service to integrate with 
the WINS database. This will provide better support for your non—Windows 2000 client 
computers. 


If you are planning on using Windows 2000 DNS name servers with other implementa- 
tions of name servers, be sure to review the online help to determine which versions 
integrate well with Windows 2000 DNS. Test the interaction between the Windows 2000 
DNS server and the other DNS servers and view the log files for DNS to ensure that 
replication of data is occurring correctly. 


GROWING A DNS 
IMPLEMENTATION 


This chapter will discuss considerations on growing a DNS implementation — 
to better meet your organization’s needs. Many of the topics here are ideas 
that will work in larger implementations and may not be well suited for 
smaller implementations. As Windows 2000 becomes the predominant net- 
work operating system and more people begin to deploy Windows 2000's 
DNS, many of the ideas may become best practices. 


Remember, there is no one solution that fits every organization’s needs. As a 
designer, implementer, or administrator, you will have to continually per- 
form server and network analysis within your organization to form a trend 
that can be compared to “baseline” to help predict future network needs and 
when it is approaching the time for any upgrades. 


Bigger Server Versus More Servers 


This is a question that is often asked. Should I upgrade my DNS server and 
make it more powerful, or should I simply add more DNS servers? 
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There is no simple answer to this question because there are never any simple answers to net- 
work questions. There are several things that you will need to consider: 


Your organization should always have a minimum of two DNS servers. This allows for 
fault tolerance and some load balancing. 


You need to consider how large your organization is and, more importantly, what the 
volume of traffic is that is being generated to your DNS servers. For organizations that 
have a lot of hosts that generate a lot of DNS server traffic, multiple servers may be an 
appropriate option. 

If you are running “internal” DNS servers, placement of these servers can have a dra- 
matic impact on network performance. Generally speaking, you would want to put DNS 
servers closer to the hosts that utilize them the most frequently. 


Determine the relative impact to the network infrastructure by adding additional DNS 
servers. The network infrastructure may not be able to handle the additional network 
traffic for zone transfers to the additional servers. 


If your zones are not Active Directory integrated, you may not be getting the most out of 
Windows 2000’s DNS. 


Adding additional servers provides more administrative duties for maintaining the net- 
work and also provides more chances for hardware failures. Maintaining multiple 
servers is not always the most desirable situation. 


Remember that typical DNS servers can handle thousands of queries per second. The real 
issues here are network performance, administration of multiple servers, and cost. 


Advantages and Disadvantages of Single, More-Powerful 
Servers 
There are always advantages and disadvantages of using single, more-powerful servers. When 


implementing or upgrading your network, think about the overall effect your design will have 
on server and network performance. Advantages of this implementation include the following: 


Less hardware to maintain 

Less expensive in the long run 

Easier to upgrade in the future 

Less impact on performance of network 


Easier to administer 


Disadvantages of single, more-powerful servers are that they have 


H A single point of failure—No fault tolerance. 


Less selection of servers off the store shelf—Powerful servers are not typically found at 
the local computer store. They are specially ordered or built. 
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M Expensive upfront cost—Powerful servers are typically more expensive to purchase. 


E No load balancing—Network performance can suffer in large volume organizations 
requiring efficient performance through DNS. 


M Potential for failures due to “physical layer” problems—Routers that go down or become 
dysfunctional can prevent hostname resolution from remote networks. 


Advantages and Disadvantages of Multiple Smaller 
Servers 


As when using a single powerful server, there are advantages and disadvantages when consid- 
ering the use of multiple servers. As a network designer or administrator, you will need to 
determine which scenario best meets the needs of your organization. The advantages include 
the following: 


Æ No single point of failure—Fault tolerance. 


E Load balancing—Built-in ability to place a DNS server on each segment or subnet or 
your network. 


W Reduced network load—Placing a DNS on each segment or subnet will reduce a lot of 
remote network traffic associated with DNS queries. 


M Reduced “physical layer” failures 


Disadvantages of multiple smaller servers can include the following: 


Œ More hardware to maintain 

M@ More administrative functions—Having to configure, manage, and maintain multiple 
servers. 7 

M@ Harder to upgrade across the board 


E Greater impact on network performance—If zones are configured to transfer information, 
network traffic will be increased. 


The general rule of thumb or best practice is to add multiple servers throughout your network. 
The next section will discuss where to add servers and what type of servers you should add. 


Adding Name Servers 


The big questions are “What type of name servers do I need?” and “Where do I put them?” 
There are no right or wrong answers to these questions. The questions are answered by look- 
ing at your network and determining where the name servers could best benefit the most 
users. The following are some guidelines that may help you determine how many servers you 
should have and where to place them. 
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Consider placing at least one name server on each network, subnet, or segment. This 
prevents the router from becoming the point of failure. 


For networks or subnets that generate a lot of queries, consider placing multiple servers 
to help load balance requests. 


Consider placing name servers on file servers that service diskless nodes. 


Consider running a name server offsite. An ISP or a sister organization may be a good 
choice. For many smaller organizations, their main means of name resolution comes 
from their ISP. Why not take advantage of this same concept in your midsize to larger 
organizations? 


Consider using “multihomed” nodes as a name server. By definition, a “multihomed” 
node has a connection to multiple networks or subnets. This works well in smaller to 
midsize organizations. 


Look at your physical network connectivity. If you have a high-powered server serving 
as the name server with poor connectivity, performance is still an issue. Consider some 
of the following ideas: 


1. Put multiple network adapters in the name server. Using multiple adapters 
allows you to 


E Bind the server service to one adapter and the workstation (redirector) to the 
other adapter. This provides control of how information comes and goes 
through the name server. Client traffic (queries) only comes in the card with 
the server service bound to it. For zone transfers between DNS server, the 
card with workstation service bound to it is used. This can prevent some bot- 
tlenecking at the physical layer of the name server. 

HM Connect each adapter to a separate network or subnet. This will reduce the 
volume of traffic on each adapter and can provide greater overall performance. 

2. Place a faster card in the name server and connect it to a fast link on the router 
or hub. Even though you may be running 1OBASE-T to the desktop (hosts), if 
your name server is running 100BASE-T, performance for the name server is 
increased. 

3. Place a name server close to your Internet link. This allows for resolution to and 
from the Internet to be much more efficient. 


E Ina Windows 2000 organization, simply creating Active Directory—integrated zones can 


increase performance and reliability. This allows active directory to manage replication 
of zone information. 


In a Windows 2000 DNS implementation, doing incremental zone transfers will greatly 
increase performance. Instead of having to do full zone transfer that may take a large 
chunk of bandwidth and time, incremental zone transfers can greatly enhance perform- 
ance, especially if there are many changes. 
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Configuring Round Robin 


You may also want to consider configuring round robin on your internal root server. Round 
robin is a local load-balancing mechanism used by DNS servers to share and distribute net- 
work resource loads. In larger organizations that choose to run their own root servers, round 
robin can be configured to delegate the load of internal DNS servers. Simply create multiple 
resource records in the root for a zone pointing to different name servers. When round robin is 
configured on a DNS server, the DNS server replies to name queries for a particular host that 
is configured with multiple TCP/IP addresses; it “shuffles” the address records. For example, if 
you had three Web servers that all contained the same information, you could configure a host 
record that contains all three TCP/IP addresses within DNS. The entry would look something 
like the following: 


webserver IN A 192.168.0.1 
IN A 192.168.0.2 
IN A 192.168.0.3 


When DNS receives a query for webserver the first time, it will respond with 192.168.0.1. The 
second query’s response will be 192.168.0.2, and the third query would result in a response of 
192.168.0.3. A fourth query would result in the response of 192.168.0.1. 


This technique can also be used on your root servers. The process is the same as the previous 
example, except that you would make the TCP/IP address point to internal DNS servers for a 
particular zone. 


There is one caution to add here. The tt1 for these records that are configured in a round- 
robin fashion should be set to a minimum. For example, the default tt1 for a resolved host is 
3,600 seconds or 1 hour; consider making the tt1 for resource records configured in a round 
robin to 60 seconds. This ensures that if the addresses are cached on an intermediate name 
server that does not support round robin, the names will drop out of the cache in a very short 
period of time. This way, if an intermediate name server needs to look up the name again, the 
root server can round robin the addresses again, thus providing the load balancing. 


~ Load Balancing Versus Load Sharing 
: | The term “load balancing” used here is a little misleading. Because the DNS servers do not actually query each identified server 
to see how busy they really are, there really is no load balancing. A more appropriate term would be load sharing. 


The guidelines that were presented here are not a catchall to organizing your name servers. To 
determine if more servers are better, you will need to use tools like Performance Monitor and 
Network Monitor. These tools can tell you if a server is overworked and becoming a bottle- 
neck, what the load of name query and resolution is on your network, and which individuals 
or subnets are generating the majority of the traffic. Using this information, you make the 
determination whether to upgrade servers or to add more servers. Some of this information 
may also provide clues that clients may be incorrectly configured. 
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After you have determined that you need to add additional name servers, you need to decide 
what type of name server(s) to add. The common solution would be to add a bunch of slave 
name servers. This may seem like a great idea, but you can cause the primary name server 
to become overburdened trying to keep up with all of the slave requests for updates. 


In Windows 2000, overburdening the primary name server can be avoided or reduced by 
implementing Active Directory—integrated zones. All zone information is transferred through 
Active Directory replication. In fact, the recommendation for DNS in Windows 2000 will be to 
create Active Directory—integrated zones. 


If an organization decides to implement primary zones on its name servers, you could create 
multiple secondary servers and place them throughout the network to provide for load balanc- 
ing. To prevent overburdening the primary name server with zone transfers to all of the sec- 
ondary name servers, configure a few of the secondary name servers as “slave” servers from 
the primary name server. These secondary servers can now be configured as “master” servers 
for any additional secondary servers that you configure on your network. This provides load 
balancing for zone transfers. 


Of course, you could just create several primary name servers to eliminate the additional traf- 
fic required for zone transfers. Doing this causes extra work for the administrator because you 
will have to manually synchronize your database files. As an administrator, you should look 
for ways to minimize the amount of extra work that you need to do to keep the network run- 
ning smoothly and efficiently. The best method in Windows 2000 is to integrate zones into 
Active Directory. 


Another type of name server that you can implement is a cache-only name server. The cache- 
only name server does not need much configuration because it only caches information. When 
setting up a cache-only name server, you simply point it to one or more authoritative name 
servers on your network or on the Internet. In fact, for most smaller organizations that will 
not want to manage many DNS servers, this is the way to go. There is nothing for you to con- 
figure except TCP/IP addresses to your ISP’s DNS server(s). Cache-only DNS servers can be 
placed throughout your network to help load balance client requests. A cache-only DNS server 
has the ability to resolve queries on the internal network as well as the external network. The 
value of a cache-only DNS server comes after it builds up its cache. If clients on your network 
tend to access the same information, after a cache-only server resolves the name and stores it 
in its cache, it does not need to go out each time a different client requests the same informa- 
tion. This saves bandwidth and increases overall performance. 


As you can tell, there are many ways to implement name servers on your network and 
throughout your organization. Each organization is unique in its needs. What works for one 
organization may not work for another. Effective planning, documentation, and communica- 
tion will be integral parts to setting up, maintaining, and growing your DNS organization. 
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Changing Time to Live (TTL) to Reduce 
Workload 


Simply adding servers to a network is not the only way to increase performance and balance 
workload. There are some configuration options in DNS that can also play an important role 
in achieving performance and efficiency. 


Time to Live (TTL) for resource records is the time, in seconds, that any server will cache that 
record. This means that if a name server resolves a name from another name server (internal 
or external), it will only cache that information for a specified period of time. By default in 
Windows 2000, the TTL is 3,600 seconds, or 1 hour. After one hour, for any queries for a name 
that was previously cached and discarded, the server will have to start the resolution process 
over again. 


TTLs can be increased for resource records that will allow name servers to cache the resolved 
entries for a longer period of time. What you change the TTL to will depend on how often your 
resource records change. Increasing TTLs can allow for more efficient resolution for clients 
and reduce overall network traffic. However, in networks that rapidly change, increasing TTLs 
to too large a value can cause resource records to become stale or out of date. If a resource 
record becomes outdated (inaccurate), clients may not be able to access data that is needed. 
The right TTL to set will depend on how rapidly a network changes. If you are allowing 
dynamic updates to your internal DNS server from DHCP clients, your TTL should not be set 
to a large value—probably less than 24 hours. If, on the other hand, your organization is using 
static IP addressing, longer TTLs may be more appropriate. These values can always be 
changed as needed. An experienced administrator will know when to change TTLs to best suit 
the organization’s needs. 


Modifying Start of Authority Resource Records 


One last configuration that we will talk about is modifying values in the SOA resource record. 
The most definitive values to modify are refresh and expire. 


HM Refresh—tThis value controls how often a “slave” server will poll the “master” server for 
updates. The default value here is 3,600 seconds, or one hour. 


E Kxpire—This value determines how long data can be stored on a “slave” server without 
being updated before it discards the data and stops responding to queries. The default is 
86,400 seconds, or 24 hours. 


Both of these values can be increased in the SOA resource record on the primary name server. 
Increasing these values will reduce network traffic and workload on “master” servers because 
they will not be queried as often for updates. 
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To obtain the right values for your organization, you will have to experiment, track the trends, 
and make additional adjustments. 


Modification of SOA resource records 
In Windows 2000 implementation of DNS, there are two basic ways to modify the SOA resource record values. The first way is to 
use the GUI interface through DNS, and the second way is to modify the appropriate zone. dns file using a text editor. 


Implementing Active Directory—integrated zones will greatly reduce the amount of traffic 
required for updates and increasing the values of refresh and expire becomes much more of a 
viable solution. Windows 2000 also allows for incremental zone transfers, which significantly 
reduces the network traffic in large DNS organizations. 
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Incremental Zone Transfers 
Incremental zone transfers refer only to transferring the changes that have occurred rather than doing a full zone transfer every 


hour by default. In large organizations with large zone databases, this can greatly reduce the amount of network traffic related to 
zone transfers. 


SECURING AND 
TROUBLESHOOTING DNS 
COMMUNICATIONS 


The goal of this chapter is to assist you in securing and troubleshooting 
your DNS implementation in a Windows 2000 environment. Topics we'll dis- 
cuss include 


M Securing Windows 2000 DNS 

Testing and monitoring your DNS implementation 
Using nslookup 

Other diagnostic tools 

Troubleshooting Windows 2000 DNS 
Interoperability problems 


Security and the ability to effectively troubleshoot in today’s networks are 
always primary concerns for most organizations. With the introduction of 
Active Directory Integrated Zones and its many security features, Windows 
2000 can perform both secure updates of dynamic DNS resource records and 
secure zone transfers. Essential to the security and troubleshooting process 
is the ability to effectively test your DNS implementation. This can be 
accomplished with simple and recursive query tools that are provided with 
the DNS administrative console. After you have completed your test, you'll 
want to continually monitor your DNS environment for changes that might 
occur. Debug logging options and the DNS server system log in event viewer 
are tools in Win2K that help administrators with this function. 
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Not to be overlooked in your DNS toolbox is one of the most commonly used tools for manually 
performing DNS queries and testing, nslookup. It is available on both Windows’s client and 
server operating systems with the TCP/IP protocol stack installed. The use of other TCP/IP 
and DNS diagnostic tools, such as Dnscmd, ping, traceroute, ipconfig, netstat, and nbtstat, 
should also be considered in any TCP/IP or DNS testing/troubleshooting scenario. 


When it comes to troubleshooting DNS specific problems, you will have to determine where 
the problem is originating from in the network. These problems can often be associated with 
the DNS client, the DNS servers, the dynamic updates, or the DNS zones. We will specifically 
address each of these areas and attempt to determine causes and solutions for commonly seen 
problems that can arise. 


With the final release of Windows 2000 (Win2K) finally on store shelves, companies have 
started to take a much closer look at the issues related to the migration from Windows NT 4.0 
to Windows 2000. One of the many issues facing mid- to large-size companies is the fact that 
they operate in heterogeneous environments. The combination of NT 4.0, UNIX/Linux, Novell, 
and the like are commonly seen within the same network. This fact presents the issue of inter- 
operability between existing and primarily established UNIX BIND DNS servers and 
Microsofts Windows 2000 DNS. 


__ Defining Security 
L Security (also called IT Security and InfoSec) is the means and methods of protecting your data from unauthorized access, theft, 
ıı alteration, or deletion and ensuring your own continued ability to access your own data whenever required. 


Securing Windows 2000 DNS 


Many of Win2K’s new features relate to security. When you look at the new features, such as 
Kerberos, Active Directory (AD), and integrated support for public key infrastructure (PKI), 
you might think Microsoft replaced most of the security architecture of Windows NT. In fact, 
Microsoft has exploited many features of NT’s original security architecture. Even with | 
Kerberos, AD, and PKI, the core of Win2K security builds on NT 4.0’s security infrastructure. 


Microsoft designed Win2K with several goals in mind. One was to address NT 4.0’s shortcom- 
ings and the other was to position the new operating system (OS) as the ultimate enabler for 
e-commerce. First, Microsoft designed Win2K for improved security. Microsoft replaced NT 
LAN Manager (NTLM) network authentication with Kerberos to address NTLM vulnerabili- 
ties. You can use Win2K’s support for Public Key Infrastructure (PKI) to eliminate the risks 
inherent to passwords, and you can use smart cards to mitigate the risks of private keys (the 
secret half of a cryptographic key pair). PKI also enables you to secure Internet Protocol (IP) 
network traffic using a protocol called IPSec. 
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Windows 2000 includes a set of security components that make up the Windows security 
model. These components ensure that applications cannot gain access to resources without 
proper authentication and authorization. These applications can include your DNS updates, 
zones transfers, or any other service-related feature of Windows 2000. Components of the secu- 
rity subsystem run in the context of the Lsass.exe process and include the following: 


W Local Security Authority (LSA) 
Netlogon service 

Security Accounts Manager service 
LSA Server service 

Secure Sockets Layer 


NTLM and Kerberos authentication protocols 


The security subsystem keeps track of security policies and the accounts that are being 
enforced on Windows NT computer systems. In the case of a domain controller, these policies 
and accounts are in effect for the domain in which the domain controller is located and author- 
itative. These security components are stored in Active Directory. The Local Security Authority 
(LSA) is a protected subsystem that maintains the information about all aspects of local secu- 
rity on a system and is collectively known as the local security policy. The LSA provides vari- 
ous services for translation between names and identifiers. 


In general, the LSA performs the following functions: 


W Manages local security policy. 
W Provides interactive user authentication services. 


M Generates tokens that contain user and group information, as well as information about 
the security privileges for a user. After initial logon is complete, all users are identified 
by their security identifiers (SID) and the associated access tokens. 


E Manages the Audit policy and settings. When the Security Reference Monitor generates 
an audit alert, the LSA is charged with writing that alert to the appropriate system log. 


The local security policy identifies the following: 


E Domains trusted to authenticate logon attempts 
Who can have access to the system and in what way 
Who is assigned privileges 

What security auditing is going to be performed 


Default memory quotas (paged and nonpaged memory-pool usage) 
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A key security component that is new to the Windows NT realm is Kerberos. Kerberos V5 is 
the primary security protocol for authentication within a Windows 2000 domain. The Kerberos 
V5 protocol verifies both the identity of the user and network services. This dual verification 
process is known as mutual authentication. Only Windows 2000 servers and workstations can 
use this type of authentication method. 


The Kerberos V5 authentication mechanism issues tickets for accessing network services. 
These tickets contain encrypted data, including an encrypted password that confirms the 
user’s identity to the requested service. Except for entering a password or smart card creden- 
tials, the entire authentication process is invisible to the user. An important service within 
Kerberos V5 is the Key Distribution Center (KDC). The KDC runs on each domain controller 
as part of Active Directory, which stores all client passwords and other account information. 


The Kerberos V5 authentication process works as follows: 


1. The user on a client system, using a password or a smart card, authenticates to 
the KDC. 


2. The KDC issues a special ticket-granting ticket to the client. The client system uses this 
TGT to access the ticket-granting service (TGS), which is part of the Kerberos V5 
authentication mechanism on the domain controller. 


3. The TGS then issues a service ticket to the client. 


4. The client presents this service ticket to the requested network service. The service ticket 
proves both the user’s identity to the service and the service’s identity to the user. 


You might also look into using Internet Protocol Security (IPSec) as an additional security 
measure to protect your DNS zone updates and other sensitive data while it is transmitted 
over your network. IPSec is a suite of protocols based on standards developed by the IPSec 
working group of the Internet Engineering Task Force (IETF) and is a new security feature 

in Windows 2000. IPSec operates at the TCP/IP transport layer or host-to-host layer (Open 
Systems Interconnection network layer 3). When properly implemented, it is transparent to 
the operating system and applications. You can use IPSec to provide secure and private end-to- 
end communications over IP networks for IPSec-aware clients and servers. You can use IPSec 
to perform the following security tasks: 


© Authenticate the sender of IP data packets based on Kerberos trust, digital certificates, 
or shared secret key (password). 


Æ Ensure the integrity of the IP data packets transmitted over the network (zone trans- 
fers). 


E Encrypt all data sent over the network for full confidentiality. 


Æ Hide the originating IP addresses from observation while en route. 
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You can define Internet Protocol Security (IPSec) policies for each domain. IPSec policies 
include rules that determine how IPSec is used for clients in the domain. Rules can control 
IPSec communications between clients in specified filter lists. You can configure IPSec policies to 


HM Specify the levels of authentication and confidentiality required between IPSec clients. 


M@ Specify the lowest security level at which communications are allowed to occur between 
IPSec-aware clients. 


wŒ Allow or prevent communications with non-[PSec—aware clients. 


W Require all communications to be encrypted for confidentiality or you can allow commu- 
nications in plain text. 


Consider using IPSec to provide security for the following types of applications: 


E Peer-to-peer communications over an intranet 


Æ Client/server communications to protect sensitive (confidential) information stored on 
servers 


M Remote access (dial-up or virtual private network) communications 


Æ Secure router-to-router WAN communications 


These security components work hand in hand with Microsoft’s Active Directory (AD). AD is 
Win2K’s flagship component and addresses NT 4.0’s directory problems of scalability, extensi- 
bility, administration, and security. NT 4.0 didn’t scale well for large organizations because it 
limited domains to 26,000 users, and the PDCs and BDCs used a one-to-many replication 
process. In Win2K, one AD domain can contain a million objects and doesn’t require a PDC. 
Changes recorded on any domain controller replicate to the rest. You can tune this multimas- 
ter replication as necessary to provide performance and safeguard bandwidth for geographi- 
cally dispersed organizations. To accomplish this task, you use a new NT object called sites, 
which are related to IP subnets. Sites let you separate domains that are often based on organi- 
zational boundaries, from geographic boundaries. DNS zone updates can be made part of this 
multimaster replication process through the use of Active Directory Integrated Zones. After 
this is accomplished, your DNS deployment can begin to take full advantage of the rich secu- 
rity features of Windows 2000. 


Security in a Standard Zone Storage Model 


In a standard zone storage model, DNS updates are conducted based on a single-master 
update model. In this model, a single authoritative DNS server for a zone is designated as the 
primary source for the zone. This server maintains the master copy of the zone in a local file. 
With this model, the primary server for the zone represents a single fixed point of failure. If 
this server is not available, update requests from DNS clients are not processed for the zone. 
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The transfer of zone updates has a very limited security mechanism. The only real security 
available is to maintain a DNS notify list on the primary servers. Windows DNS servers sup- 
port DNS Notify, an update to the original DNS protocol specification that permits a means of 
initiating notification to secondary servers when zone changes occur (RFC 1996). DNS notifi- 
cation implements a push mechanism for notifying a select set of secondary servers for a zone 
when it is updated. Servers that are notified can then initiate a zone transfer to pull zone 
changes from their master servers and update their local replicas of the zone. 


For secondaries to be notified by the DNS server acting as their configured source for a zone, 
each secondary server must first have its IP address in the notify list of the source server. 
When using the DNS console to manage a zone loaded at Windows 2000 DNS servers, this list 
is maintained in the Notify dialog box, which is accessible from the Zone Transfer tab located 
in zone Properties. 


In addition to notifying the listed servers, the DNS console permits you to use the contents of 
the notify list as a means to restrict or limit zone access to only those secondary servers speci- 
fied in the list. This can help prevent an undesired attempt by an unknown or unapproved 
DNS server to pull, or request, zone updates. Keep in mind that this means of update is still 
subject to hackers impersonating one of your DNS servers. It is also subject to what is known 
as “man-in-the-middle” attacks. This type of attack is executed when a hacker intercepts or 
alters your information while it is in transit from point A to B. If you use this method of 
update, you might want to consider using a Win2K [PSec implementation between your pri- 
mary and secondary DNS servers to ensure secure updates. If these updates travel between 
your internal (firewall protected) and external network, you should definitely give [PSec a 
hard look. 


Multimaster Update and Enhanced Security Based on 
the Capabilities of Active Directory 


With directory-integrated storage, dynamic updates to DNS are conducted based on a multi- 
master update model. In this model, any authoritative DNS server, such as a domain con- 
troller (DC) running the Windows 2000 DNS Server service, is designated as a primary source 
for the zone. Because the master copy of the zone is maintained in the Active Directory data- 
base, which is fully replicated to all domain controllers, the DNS servers operating at any DC 
for the domain can update the zone. With the multimaster update model of Active Directory, 
any of the primary servers for the directory-integrated zone can process requests from DNS 
clients to update the zone as long as a DC is available and reachable on the network. 


This multimaster replication process is secured with Win2K security features, such as 
Kerberos, by way of RPC (Remote Procedure Call) over IP or SMTP (Simple Mail Transfer 
Protocol) communication. If you choose to use SMTP for intersite transfer of information, you 
must install and configure an enterprise certification authority. The certification authority 
(CA) signs SMTP messages that are exchanged between domain controllers, ensuring the 
authenticity of directory updates. Remote replication uses 56-bit encryption. RPC over IP 
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intrasite replication, on the other hand, does not require a CA for secure multimaster 
replication. These security mechanisms make attacks from external intruders and mischievous 
internal users much more difficult. 


When using directory-integrated zones, you can use access control list (ACL) editing to secure 
a DNS zone object container in the Active Directory tree. This feature provides granulated 
access to either the zone or a specified resource record in the zone. For example, an ACL for a 
zone resource record can be restricted so that dynamic updates are allowed only for a specified 
client computer or a secure group, such as a domain administrators group. This security fea- 
ture is not available with standard primary zones. Keep in mind that when you change the 
zone type to be directory integrated, the default for updating the zone changes to allow only 
secure updates. 


To modify security (ACL) for a resource record, do the following: 


. Open the Microsoft Management Console with the DNS snap-in. 
- In the console tree, click the applicable zone. 

In the details pane, click the record you want to view. 

© On the Action menu, click Properties. 
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© On the Security tab (see Figure 12.1), modify the list of member users or groups that are 
allowed to securely update the applicable record and reset their permissions as needed. 
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Figure 12.1 The resource record ADVSERVER can be secured by using the Security tab on 
the resource record’s Properties page. 
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To modify security (ACL) for a directory-integrated zone, do the following: 


Open the Microsoft Management Console with the DNS snap-in. 
In the console tree, click the applicable zone. 
On the Action menu, click Properties. 


On the General tab (see Figure 12.2), verify that the zone type is Active Directory— 
integrated. 
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Figure 12.2 The General tab on the property sheet for the loux.com zone allows user to 
identify and change the zone type. 


5. On the Security tab, modify the list of member users or groups that are allowed to 
securely update the applicable zone and reset their permissions as needed. 


If the check boxes are shaded when you view the security properties of an object in DNS, the 
object has inherited permissions from the parent object. There are three ways to make changes 
to inherited permissions: 


E Make the changes to the parent object, and the object will inherit these permissions. 


HM Select the opposite permission (Allow or Deny) to override the inherited permission (see 
Figure 12.3). 
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Figure 12.3 Selecting the Deny permission for read and write will override the inherited 
read and write permission. 


M Clear the Allow Inheritable Permissions from Parent to Propagate to This Object check 
box shown in Figure 12.4. Now you can make changes to the permissions or remove 
users or groups from the permission list. However, the object will no longer inherit per- 
missions from the parent object. 
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Figure 12.4 Clearing the Allow Inheritable Permissions from Parent to Propagate to This 
Object check box results in a Security dialog box. 


Default Dynamic Update Security 


Win2K DNS clients attempt to use unsecured dynamic update first. If an unsecured update is 
refused, clients try to use secure update. Also, clients use a default update policy that permits 
them to attempt to overwrite a previously registered resource record, unless they are specifi- 
cally blocked by update security. 
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After a zone becomes Active Directory—integrated, Win2K DNS servers default to allowing 
only secure dynamic updates. When using standard zone storage, the default for the DNS 
Server service is to not allow dynamic updates on its zones. For zones that are either 
directory-integrated or use standard file-based storage, you can change the zone to allow all 
dynamic updates, which permits all updates to be accepted, by passing the use of secure 
updates. 


For Windows 2000 Server, the DHCP Server service can perform proxy registration and 
update of DNS records for legacy clients that do not support dynamic updates. If you use mul- 
tiple Win2K DHCP servers on your network and also configure your zones to allow secure 
dynamic updates only, you need to use Active Directory Users and Computers to add your 
DHCP server computers to the built-in DnsUpdateProxyGroup. This will permit all of your 
DHCP servers the secure rights to perform proxy updates for any of your DHCP clients. 


| If you use the DnsUpdateProxyGroup for your DHCP servers, all service location (SRV), host (A), or alias (CNAME) resource records 
| registered by the Netlogon service for the domain controller are nonsecure. To avoid this security problem, deploy DHCP servers 
«| and domain controllers on separate computers. 


Security Concerns When Using the 
DnsUpdateProxyGroup 


Although adding all DHCP servers as members to this special built-in group helps to resolve 
some DNS update concerns about maintaining secure updates, this solution also introduces 
some additional security concerns. For example, any DNS domain names registered by the 
computer running the DHCP server are nonsecure. The host (A) resource record for the DHCP 
server itself is an example of an unsecured record. This issue is more significant if the DHCP 
server that is a member of the DnsUpdateProxy group is installed on a domain controller. To 
protect against this issue, you can manually specify a different owner for any DNS records 
associated with the DHCP server itself. In this case, all service location (SRV), host (A), or 
alias (CNAME) resource records registered by the Netlogon service for the domain controller 
are nonsecure. To minimize the problem, it is recommended that you do not install a DHCP 
server on a domain controller. 


Another strong argument against running a Win2K DHCP server on a Win2K domain con- 
troller is that because the DHCP server is running under the domain controller account, the 
DHCP server has full control over all DNS objects stored in Active Directory. 
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Testing and Monitoring Your DNS 
Implementation 


When using the DNS console, you can perform either manual or automated verification testing 
of your DNS servers to monitor their capability to process and resolve queries. This feature is 
accessed through the Monitoring tab in DNS server Properties. 


When using this feature, two types of tests are available. The first is a simple query against 
the DNS server. This type of test specifies that the DNS server performs a simple or iterative 
query. This test is a localized query using the DNS resolver (client) on the server computer to 
query the local DNS server, also located on the same computer. 


The second type of test is a recursive query to other DNS servers. This type of test specifies 
that the DNS server perform a recursive query. This test is similar in its initial query process- 
ing to the previous test in that it uses the local DNS resolver (client) to query the local DNS 
server, also located on the same computer. In this test, however, the client asks the server to 
use recursion to resolve an NS-type query for the root of the DNS domain namespace, stated 
as a single dot (.). This type of query should typically require additional recursive processing 
and can be helpful in verifying that server root hints or zone delegations have been 

properly set. 


After you have selected the tests to be used, you can either click the Test Now button to manu- 
ally perform the tests immediately, or you can perform automatic testing at a specified time 
interval. 


Automated tests are performed periodically when the Perform Automatic Testing at the 
Following Interval check box is selected and are performed according to the duration config- 
ured in Time Interval. 


Results of all selected tests, whether manually or automatically performed, are displayed in 
the Test Results list box. Typically, this information includes the following: 


W The date and time when each query was made. 


Œ Additional status results of the specific test used, such as whether the simple or recur- 
sive query failed or succeeded. Unfortunately, these test results cannot be saved to a file 
for later use. 


After your testing is completed and successful, you'll want to provide for continued monitoring 
of your DNS infrastructure. You can start by selecting and enabling debug logging options on 
the DNS server. 
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To select and enable debug logging options on the DNS server, do the following: 


Open the DNS console. 

In the console tree, click the applicable DNS server. 
On the Action menu, click Properties. 

Click the Logging tab. 


Select the events that you want the DNS server to record for debug logging, and then 
click OK. 
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7 Debug Logging Options 
_. Using debug logging options slows DNS server performance. For this reason, all debug logging options are disabled by default. 


For Win2K DNS servers, the following debug logging options are supported for use: 


Æ Query—Logs queries received by the DNS Server service from clients 


E Notify—Logs notification messages received by the DNS Server service from other 
servers , 


E Update—Logs dynamic updates received by the DNS Server service from other 
computers 


E Questions—Logs the contents of the question section for each DNS query message 
processed by the DNS Server service 


HM Answers—Logs the contents of the answer section for each DNS query message 
processed by the DNS Server service 


E Send—Logs the number of DNS query messages sent by the DNS Server service 
E Receive—Logs the number of DNS query messages received by the DNS Server service 


E UDP—Logs the number of DNS requests received by the DNS Server service over a 
UDP port 


E TCP—Logs the number of DNS requests received by the DNS Server service over a 
TCP port 


E Full packets—Logs the number of full packets written and sent by the DNS Server 
service 


E Write through—Logs the number of packets written through by the DNS Server service 
and back to the zone 


To view the DNS server debug log file, do the following: 


1. Stop the DNS service. 
2. Open WordPad. 
3. On the File menu, click Open. 
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4, For File Name, specify the path to the DNS server debug log file. By default, if the 
applicable DNS server is running locally, the file and path are as follows: 


%SystemRoot%\System32\Dns\Dns.log 


5. After you specify the correct path and file, click Open to view the log file shown in 
Figure 12.5. 
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Figure 12.5 DNS server debug log is located in a file called DNS. log. 


You can also monitor your DNS activity by way of the Windows 2000 Event Viewer. To view 
the DNS server system event log, do the following: 


1. Open Microsofts Event Viewer. 


2. Ifthe DNS server for which you want to view the log is located on another computer, do 
the following: 


a. On the Action menu, click Connect to Another Computer. 


b. Select another computer and specify the name or IP address of the remote com- 
puter. 


3. In console tree, click DNS Server. 


4. Inthe Details pane, you can view the listing of events the DNS Server service has logged. 
To view additional details for a specific event, double-click the event (see Figure 12.6). 
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Figure 12.6 Double-clicking a specific event listed in the Details pane of the DNS Server 
service log will display detailed event properties. 


Using nslookup 


This diagnostic tool displays information from Domain Name System (DNS) name servers. 
Before using this tool, you should be familiar with how DNS works. nslookup is available only 
if the TCP/IP protocol has been installed. Used as a client resolver, nslookup can directly query 
a server for information. Used on a server, nslookup can perform zone transfers from a primary 
or master server. This tool has two modes: interactive and noninteractive. If you need to look 
up only a single piece of data, use noninteractive mode. Start by typing the name or IP 
address of the computer to be looked up for the first augment. For the second argument, type 
the name or IP address of a DNS name server. If you omit the second argument, the default 
DNS name server is used. 


If you need to look up more than one piece of data, you can use interactive mode. This can be 
accomplished by typing a hyphen for the first argument and the name or IP address of a DNS 
name server for the second argument. If you omit both arguments, the default DNS name 
server will be used. 


The following is the proper syntax for nslookup: 


nslookup [-option ...] [computer-to-find | - [server]] 
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The following parameters can be used: 


M -option—Specifies one or more nslookup command as a command-line option. Each 
option consists of a hyphen (-) followed immediately by the command name and, in some 
cases, an equal sign (=) and then a value. For example, to change the default query type 
to host (computer) information and the initial timeout to 20 seconds, you would type: 


nslookup -querytype=hinfo -timeout=10 


The command-line length must be less than 256 characters. 


Mi computer-to-find—Looks up information for computer-to-find using the current default 
server or using a specified server. If computer-to-find is an IP address and the query 
type is A or PTR, the name of the computer is returned. If computer-to-find is a name 
and does not have a trailing period, the default DNS domain name is appended to the 
name. This behavior depends on the state of the set options: domains, srchlist, defname, 
and search. 


To look up a computer not in the current DNS domain, append a period to the name. If 
you type a hyphen (-) instead of computer-to-find, the command prompt changes to 
nslookup interactive mode. 


WE server—Specifies to use this server as the DNS name server. If you omit server, the 
default DNS name server is used. 


There is also a series of subcommands that can be used with nslookup. The most informative of 
these is the help command. You can go to the Win2K command prompt and type nslookup and 
then press Enter. Next, type either help or ? to view the menu of commands and subcom- 
mands. You can also query the Win2K online help for “nslookup subcommands” to get a brief 
explanation of each subcommand. 


Other Diagnostic Tools 


Win2K provides several command-line utilities other than nslookup that you can use to man- 
age and troubleshoot DNS servers and clients. These utilities include Dnscmd, ping, traceroute, 
ipconfig, netstat, and nbtstat. 


Automating Server Administration Using Dnscmd 


Provided with Windows 2000 Server, Dnscmd is a command-line interface for managing DNS 
servers. This tool can be used to script batch files, automate DNS management, and perform 
an update of existing DNS server configurations. It can also be used to perform setup and con- 
figuration of new DNS servers on your network. The following is the proper syntax used with 
this utility: 


DnsCmd <ServerName> <Command> [<Command Parameters>] 
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E <ServerName>: 


.—Local machine using LPC 

IP address—RPC over TCP/IP 

DNS name—RPC over TCP/IP 

Other server name—RPC over named pipes 


E <Commana>: 


/Info—Get server or zone information 

/ResetRegistry—Reset server or zone Registry properties 
/Statistics—Query/clear server statistics data 

/Restart—Restart DNS server 

/DebugBreak—Server debug break (internal) 

/ClearCache—Clear DNS server cache 

/UpdateServerFile—Write back all zone or root-hint datafile(s) 
/ResetListenAddresses—oelect server IP address(es) to serve DNS requests 
/ResetForwarders—Set IP address(es) to forward unsolvable queries 
/EnumZones—Enumerate zones 

/ZoneAdd—Create a new zone on the DNS server 
/ZoneDelete—Delete a zone from DNS server or DS 
/ZonePause—Pause a zone 

/ZoneResume—-Resume a zone 

/ZoneReload—Reload zone from its database (file or DS) 
/ZoneWriteBack—Write back zone to file 

/ZoneRefresh—Force refresh of secondary zone from master 
/ZoneUpdateFromDs—Update a DS integrated zone by data from DS 
/ZoneResetType—Change zone type to Primary/Secondary/Disintegrated 
/ZoneResetSecondaries—Set notify list for a zone 
/EnumRecords—Enumerate records at a name 

/RecordAdd—Create a record in zone or RootHints 
/RecordDelete—Delete a record from zone, RootHints, or cache data 
/NodeDelete—Delete all records at a name 

/SbsRegister—SBS Registration 

/SbsDeleteRecord—SBS Record Delete 


Hi <Command Parameters>: 


These command parameters are different for each command. Use /? for help information 
on each command. | 
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ping 

The ping command helps to verify [P-level connectivity. When troubleshooting, you can use 
ping to send an ICMP echo request to a target computer (hostname or NetBIOS name) or IP 
address. Use ping whenever you need to verify that a computer can connect to the TCP/IP net- 
work and its resources. You can also use ping to isolate network hardware problems and 
incompatible configurations. 


It is usually best to verify that a network path exists between the local computer and a net- 
work host by first using the ping command and the IP address of the network host to which 
you want to connect. You can try to ping the IP address of the target host to see whether it 
responds, as follows: 


ping IP_address (i.e. ping 192.168.0.1) 


If this fails to return a response, you should perform the following steps when trying to trou- 
bleshoot your network connectivity problems: 


1. ping the loopback address (127.0.0.1) to verify that TCP/IP is installed and configured 
correctly on the local computer. 


2. ping the IP address of the local computer to verify that it was added to the network cor- 
rectly. 


3. ping the IP address of the default gateway to verify that the default gateway is function- 
ing and that you can communicate with a local host on the local network. 


4. ping the IP address of a remote host to verify that you can communicate through a 
router. 


The ping command has several parameters that can be used. The proper syntax includes 


ping [-t] [-a] [-n count] [-l length] [-f] [-i ttl] [-v tos] 
[-r count] [-s count] [[-j computer-list] | [-k computer-list]] 
[-w timeout] destination-list 


The following parameters include 


Æ -t—The specified computer until interrupted. 

HM -a—Resolves addresses to computer names. 

W -n count—Sends the number of ECHO packets specified by count. The default is 4. 
E 


-1 length—Sends ECHO packets containing the amount of data specified by length. The 
default is 32 bytes; the maximum is 65,527. 


M -f—Sends a Do Not Fragment flag in the packet. The packet will not be fragmented by 
gateways on the route. 
WE -i tt1—Sets the Time-to-Live field to the value specified by tt1. 


HM -v tos—Sets the Type of Service field to the value specified by tos. 
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Æ -r count—Records the route of the outgoing packet and the returning packet in the 
Record Route field. A minimum of 1 and a maximum of 9 computers can be specified by 
count. 

Hi -s count—Specifies the timestamp for the number of hops specified by count. 

WE -j computer -1ist—Routes packets by way of the list of computers specified by computer- 
list. Consecutive computers can be separated by intermediate gateways (loose source 
routed). The maximum number allowed by IP is 9. 

WE -k computer -1ist—Routes packets by way of the list of computers specified by computer- 
list. Consecutive computers cannot be separated by intermediate gateways (strict 
source routed). The maximum number allowed by IP is 9. 

E -w timeout—Specifies a timeout interval in milliseconds. 


HM destination-list—Specifies the remote computers to ping. 


tracert Utility 


tracert (Trace Route) is a route-tracing utility that is used to determine the path that an IP 
packet takes to reach a destination. The tracert command uses the IP Time-to-Live (TTL) field 
and ICMP error messages to determine the route from one host to another through a network. 


The tracert diagnostic utility determines the route taken to a destination by sending Internet 
Control Message Protocol (ICMP) echo packets with varying IP Time-to-Live (TTL) values to 
the destination. Each router along the path is required to decrement the TTL on a packet by 
at least 1 before forwarding it. When the TTL on a packet reaches 0, the router should send an 
“ICMP Time Exceeded” message back to the source computer. tracert determines the route by 
sending the first echo packet with a TTL of 1 and incrementing the TTL by 1 on each subse- 
quent transmission until the target responds or the maximum TTL is reached. The route is 
determined by examining the “ICMP Time Exceeded” messages sent back by intermediate 
routers. Some routers silently drop packets with expired TTLs and are invisible to the tracert 
utility. 


The tracert command supports several options: 
tracert [-d] [-h maximum_hops] [-j host-list] [-w timeout] target_name 
You can use the following parameters with this command: 


HM -d—Specifies that IP addresses are not resolved to hostnames 


WE -h maximum_hops—Specifies the number of hops to allow in tracing a route to the host 
named in target_name 


WE -j host-list—Specifies the list of router interfaces in the path taken by the tracert util- 
ity packets | 


E -w timeout—Waits the number of milliseconds specified by timeout for each reply 


HM target_name—Name or IP address of the target host 
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ipconfig Utility 

This command is used to view and modify IP configuration details used by Windows NT 4.0 
computer or Windows 2000 computers. This command is of particular use on systems running 
DCHP, allowing users to determine which TCP/IP configuration values the DHCP server has 
configured. Standard commands include the following: 


W ipconfig /all—Produces a full display. Without this switch, only the IP address, subnet 
mask, and default gateway values for each network card are shown. 


W ipconfig /renew—Renews DHCP configuration parameters. This option is available only 
on systems running the DHCP Client service. 


M ipconfig /release—Releases the current DHCP configuration. This option disables 
TCP/IP on the local system and is available only on DHCP clients. 


Besides these command switches that are familiar in a Windows NT 4.0 environment, there 
are additional switches used in Windows 2000 with ipconfig for the sole purpose of dealing 
with DNS issues. 


The ipconfig /registerdns command provides you with a means to manually initiate dynamic 
registration for the DNS names and IP addresses configured at a computer. This option can 
assist in troubleshooting a failed DNS name registration or in resolving a dynamic update 
problem between a client and the DNS server without requiring a client reboot. By default, the 
ipconfig /registerdns command refreshes all DHCP address leases and registers all related 
DNS names configured and used by the client computer. 


The ipconfig /displaydns command provides you with a means to view the contents of the 
DNS client resolver cache, which includes entries preloaded from the local Hosts file, as well 
as any recently obtained resource records for name queries resolved by the system. This infor- 
mation is used by the DNS Client service to quickly resolve frequently queried names before it 
queries its configured DNS servers. When the ipconfig /displaydns command is used to dis- 
play current resolver cache contents, the resulting output generally includes the local host and 
loopback IP address (127.0.0.1) mappings. This is because these mappings typically exist in 
the default contents of the local Hosts file. 


The ipconfig /flushdns command allows you to flush and reset the contents of the DNS client 
resolver cache. Resetting the cache does not eliminate entries that are preloaded from the 
local Hosts file. To eliminate those entries from the cache, remove them from this file. 


netstat Utility 


The netstat utility is used to display protocol statistics and the state of current TCP/IP connec- 
tions. These connections can be for the local computer’s or foreign computer’s IP address and 
protocol. 
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You can use the following parameters with the netstat command: 


netstat -a—Displays all connections. 

netstat -r—Displays the route table plus active connections. 
netstat -e—Displays Ethernet statistics. 

netstat -s—Displays per-protocol statistics. 


netstat -p protocol—Shows connections for the protocol specified by protocol type 
(protocol can be tcp or udp). A combination of -p used with the -s option will display 
per-protocol statistics for tcp, udp, icmp, or ip. 


netstat -n—Addresses and port numbers are not converted to names. 


nbtstat Utility 


NetBIOS over TCP/IP (NetBT) resolves NetBIOS names to IP addresses. TCP/IP provides 
many options for NetBIOS name resolution, including local cache lookup, WINS server query, 
broadcast, DNS server query, and Lmhosts and Hosts file lookup. 


nbtstat is a useful tool for troubleshooting NetBIOS name resolution problems. You can use 
the nbtstat command to remove or correct preloaded entries: 


nbtstat -n—Displays the names that were registered locally on the system by programs 
such as the server and redirector. 


nbtstat -c—Shows the NetBIOS name cache, which contains name-to-address mappings 
for other computers. 


nbtstat -R—Purges the name cache and reloads it from the Lmhosts file. 


nbtstat -RR—Releases NetBIOS names registered with a WINS server and then renews 
their registration. 


nbtstat -a -name—Performs a NetBIOS adapter status command against the computer 
specified by name. The adapter status command returns the local NetBIOS name table 
for that computer plus the media access control address of the adapter. 


nbtstat -S—Lists the current NetBIOS sessions and their status, including statistics. 


Troubleshooting Windows 2000 DNS 


As we troubleshoot Microsofts Windows 2000 dynamic DNS, four functional areas of the DNS 
infrastructure can be isolated and assessed for potential problems. These include the 


DNS client 

DNS servers 
Dynamic updates 
DNS zones 
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As each of these areas is addressed, we will look at specific errors, their possible cause, and 
the solution based on the cause. 


Troubleshooting DNS Clients 


Specific Error #1: The DNS Client Received a “Name Not Found” 
Error Message 


Possible cause #1: The client was not able to contact a DNS server because of a network- or 
hardware-related failure. 


Solution #1: Verify that the client computer has a valid and functioning network connection. 
First, check that hardware cables and network adapters are functioning properly at the client 
using basic network and hardware troubleshooting steps. If the client hardware appears to be 
installed and functioning properly, verify that it can ping other computers on the same net- 
work as previously discussed. 


_| Basics to Troubleshooting 
| Many network problems are a result of physical connectivity issues. Always start at the physical layer when troubleshooting. 


Possible cause #2: The DNS client computer does not have a valid IP configuration for the 
network. 


Solution #2: Verify that TCP/IP configuration settings for the client computer are correct, 
particularly in regard to DNS name resolution. Use the ipconfig command to verify a client’s 
IP configuration. View the command output and verify that the client has a valid IP address, 
subnet mask, and default gateway for the network where it is attached. 


Remember that if a DHCP client does not have a valid TCP/IP configuration, you can use the 
ipconfig /renew command to manually force the client to renew its IP address. Keep in mind 
that Windows 2000 Professional clients and Windows 98 Version 2 clients use Automatic 
Private IP Addressing (APIPA) when they are not able to reach a DHCP server. APIPA uses 
addresses in the range from 169.254.0.1 through 169.254.255.254. If one of your clients has 
assigned themselves one of these addresses, you will also have to perform an ipconfig /renew. 


For statically configured clients, modify the client TCP/IP properties to use valid configuration 
settings or complete its DNS configuration settings for the network. 


Possible cause #3: The DNS client cannot contact its configured DNS servers. 


Solution #3: If the DNS client has basic connectivity to the network, verify that it can contact 
a preferred or alternate DNS server. To confirm this, try pinging the preferred DNS server by 
its IP address. If you are not sure what the IP address is for the preferred DNS server, you can 
observe it by executing the ipconfig command on the client. At the client computer, type 
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ipconfig /all at the command prompt to read and note IP addresses listed in the DNS servers 
field. 


If no configured DNS servers respond to a direct ping of their IP address, the problem is most 
likely a network connectivity issue between the client and the DNS servers. If this is the case, 
follow basic TCP/IP network troubleshooting steps like those mentioned earlier in this chapter 
to fix the problem. 


Possible cause #4: The DNS server is not running or responding to queries. 


Solution #4: If the DNS client can ping the DNS server computer, verify that the DNS server 
is started and able to listen for and respond to client requests. Try using the nslookup com- 
mand to test whether the server can respond to DNS clients. 


Possible cause #5: The DNS server the client is using does not have authority for the failed 
name and cannot locate the authoritative server for this name. 


Solution #5: Confirm whether the DNS domain name the client is trying to resolve is one for 
which the configured DNS servers are authoritative. If the client is attempting to resolve the 

name host.Que.com, verify that the preferred or an alternate DNS server queried by the client 
loads the authoritative zone where a resource record for the failed name should exist. 


If the preferred server is authoritative for the failed name and loads the applicable zone, 
determine whether the zone is missing the appropriate resource records. If required, manually 
add the resource records to the zone. 


If the preferred server is not authoritative for the failed name, it likely indicates that there 
are configuration errors at the DNS server. From this point, you will have to further trou- 
bleshoot the problem at the DNS server. | 


Specific Error #2: The DNS Client Appears to Have Received a 
Response That Has Stale or Incorrect Information 


Possible cause #1: The DNS server the client is using does not have authority for the failed 
name and is using stale information from its local DNS database. 


Solution #1: Determine whether the DNS server is authoritative for the name. If the pre- 
ferred server is authoritative for the name and answered using incorrect data, it indicates that 
the applicable zone might have outdated or stale information in the applicable resource 
records. That being the case, you can add, remove, or modify the appropriate resource records 
in the zone. 


Another option where dynamic updates are enabled is to force registration and update at the 
computer targeted by the query. If the target computer is running Windows 2000, you can 
force it to update the registration of its resource records by typing ipconfig /registerdns at a 
command prompt. 
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If the preferred server is not a direct authority for the queried name, it likely answered the 
query based on information obtained and cached during an earlier recursive lookup. In this 
case, consider clearing the server’s name cache. This will force the server to use new recursive 
queries and rebuild its cache contents based on current information. | 


Possible cause #2: The preferred DNS server is a secondary server for the zone containing 
the targeted name and has outdated information. 


Solution #2: If the server that answered the client is a secondary server for the zone, the ver- 
sion of the zone in use at the secondary server might be stale and in need of updating more 
frequently. As an immediate solution, you can initiate a zone transfer at the secondary server 
to update the zone information contained on the master server. 


Other options to improve the freshness of secondary zone data include the following: 


W Specify additional master servers for the secondary server to use when refreshing the 
zone. 
WE Adjust the refresh interval on the zone slightly. This will decrease the length of time 


that all authoritative servers for the zone can use the zone before they are required to 
refresh it. 


W Configure a notify list at a master server that acts as the zone source for the secondary 
server and enable it to notify this server when the zone changes. 


Possible cause #3: The name queried was specified in error, either through user input or in a 
stored client configuration. 


Solution #3: Verify that the name was correctly specified in the application where the name 
query originated. In most cases, incorrect data in a positive query response is caused by one of 
three reasons: 


W Auser entered an incorrect DNS name at the client. 


E A short unqualified name was used at the client and completed by the local resolver 
using an unintended DNS suffix. 


W Resource records specified in the query were not updated correctly at the DNS server. 


Confirm that the user did not enter the name incorrectly. You should also verify the exact set 
of characters entered by the user when the original DNS query was made. You might have to 
check the application settings (Internet mail or Web browser configuration) used by the client 
as well. If the name used in the initial query was unqualified, try using the Fully Qualified 
Domain Name (FQDN) instead in the client application and perform the query again. When 
doing so, be sure to include the dot (.) at the end of the name to indicate that the name 
entered is an exact FQDN. If the FQDN query succeeds and returns correct data in the 
response, the most likely cause of the problem is an improperly configured DNS domain suffix 
search list used in the client resolver settings. 
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If you are using DNS in an environment that does not support dynamic updates, or generally 
administer zone data manually, you should verify that the resource records involved in 
answering the query are entered correctly. View them to ensure the record data stored in the 
zone is correct and then modify those records as needed. 


Possible cause #4: The primary zone might have missing or incorrect data. 


Solution #4: Verify that the primary server for the zone has complete and accurate data. The 
most likely cause for a primary DNS server for a zone to have missing or incomplete data is 
because of a failed update request. Support for dynamic update might not have been fully 
implemented or configured. To resolve the problem, review the DNS dynamic update protocol 
and its requirements as addressed earlier in this book. 


For directory-integrated zones, it is also possible that the affected records for the query have 
been updated in Active Directory but not replicated to all DNS servers loading the zone. By 
default, all DNS servers that load zones from Active Directory poll it in 15-minute intervals 
and update the zone for any incremental changes to it. Using default replication settings and 
reliable high-speed links, a DNS update should take no more than 20 minutes to replicate to 
all DNS servers used in an Active Directory domain environment. 


If you have specifically configured your zones to disable dynamic update, you need to manually 
add and update most types of resource records used in a zone. You can use the DNS console to 
view and update the affected records. 


Another possibility for the incorrect data is when WINS lookup integration is enabled for use 
with your zones. WINS lookup within your zones can be a source of the incorrect data and 
should be investigated separately. 


Troubleshooting DNS Servers 


Specific Error #1: The DNS Server Is Not Responding to the 
Clients 


Possible cause #1: The DNS server is affected by a network failure. 


Solution #1: Verify that the server computer has a valid functioning network connection. 
First, check that affected client hardware cables and network adapters are working properly 
as previously described. After this is ruled out as source of error, perform the same trouble- 
shooting steps on the server. If the server hardware appears to be installed and functioning 
properly, check that it has network connectivity by pinging other computers or routers that are 
in use on the same network as your DNS servers. 


Possible cause #2: The DNS server is reachable through basic network testing but is not 
responding to DNS queries from clients. 
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Solution #2: If the DNS client can ping the DNS server computer, verify that the DNS service 
on the server is started and able to listen to and respond to client requests. Once again, use 
the nslookup command to test whether the server can respond to DNS clients. 


Possible cause #3: The DNS server has been configured to limit service to a specific list of 
configured IP addresses. In this case, the IP address originally used in testing its responsive- 
ness was not included in this list. 


Solution #3: If the server was previously configured to restrict the IP addresses for which it 
responds to queries, it is possible that the IP address being used by clients for contact is not in 
the list of restricted IP addresses. You should try to test the server for a response by using an 
IP address known to be in the restricted interface list for the DNS server. If the DNS server 
responds to this address, add the missing server IP address to the restricted list. 


Possible cause #4: The DNS server has been configured to disable the use of its automati- 
cally created default reverse lookup zones. 


Solution #4: Verify that all automatically created reverse lookup zones have been created for 
the server. Also ensure that advanced configuration changes have not been previously made to 
the server. By default, Windows 2000 DNS servers automatically create the following three 
standard reverse lookup zones based on RFC recommendations: 


w 0.0.0.0 
M@ 127.0.0.1 
E 255.255.255.255 


By being authoritative for the zones corresponding to these addresses, the DNS service avoids 
unnecessary recursion to root servers. If these zones are not present, it is likely due to 
advanced manual configuration by an administrator. 


To verify that these zones have been created at a Windows 2000 DNS server, do the following: 


Open the DNS console. 
From the View menu, click Advanced. 
In the console tree, click Reverse Lookup Zones. 


E ae ae 


In the Details pane, verify that reverse lookup zones 0.in-addr.arpa, 127.in-addr.arpa, 
and 255.in-addr.arpa are present. 


Possible cause #5: The DNS server is configured to use a nonstandard service port, such as 
in an advanced security or firewall configuration. 


Solution #5: Verify that the DNS server is not using a nonstandard configuration. By default, 
the nslookup command sends queries to targeted DNS servers using User Datagram Protocol 
. (UDP) port 53. If the DNS server is located on another network reachable only through an 
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intermediate host, such as a packet-filtering router or proxy server, the DNS server might use 
a nonstandard port to listen for and receive client requests. 


If this situation applies, determine whether any firewall or proxy server configurations are 
intentionally being used to block traffic on well-known service ports used for DNS. If not, you 
might be able to add a packet filter entry on these filtering devices that will permit standard 
DNS traffic. 


Also, check the DNS server event log to see whether Event ID 414 or other critical service- 
related events which might indicate why the DNS server is not responding. 


Specific Error #2: The DNS Server Does Not Resolve Names 
Correctly 


Possible cause #1: The DNS server provides incorrect data for queries it successfully 
answers. 


Solution #1: Determine the cause of the incorrect data for the DNS server. 
Some of the most likely causes include the following: 


W Resource records (RRs) were not dynamically updated in a zone. 

E An error was made when manually adding or modifying static resource records in the 
zone. 

M@ Stale resource records in the DNS server database are left from cached lookups. Also, 


zone records might exist that are not up to date with current information or were not 
removed when they were no longer needed. 


Possible cause #2: The DNS server does not resolve names for computers or services outside 
your immediate network, such as those located on external networks or the Internet. 


Solution #2: The server has a problem based on its capability to correctly perform recursion. 
Recursion is used in most DNS configurations to resolve names that are not located within the 
configured DNS domain name used by the DNS servers and clients. If a DNS server fails to 
resolve a name for which it is not authoritative, the cause is usually a failed recursive query. 
For recursion to work successfully, all DNS servers used in the path of a recursive query must 
be able to respond to and forward correct data. 


A recursive query can fail for any of the following reasons: 


MH The recursive query times out before it can be completed. 
@ A remote DNS server fails to respond. 


HM Aremote DNS server provides incorrect data. 
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Perform various recursive queries to help isolate the problem. 


Possible cause #3: The DNS server is not configured to use other DNS servers to assist it in 
resolving queries. 


Solution #3: Check whether the DNS server can use both forwarders and recursion. By 
default, all Windows 2000 DNS servers are enabled to use recursion, although the option to 
disable its use is configurable by using the DNS console. 


Possible cause #4: Current root hints for the DNS servers are not valid. 
Solution #4: Check whether server root hints are valid. 


If configured and used correctly, root hints always should point to DNS servers authoritative 
for the zone containing the domain root and top-level domains. By default, Windows 2000 DNS 
servers are configured or updated to use root hints appropriate to your deployment, based on 
the following available choices when using the DNS console to configure a server: 


E Ifthe DNS server is installed as the first DNS server for your network, it is configured 
as a root server. For this configuration, root hints are disabled at the server because the 
server is authoritative for the root zone. 


W Ifthe installed server is an additional DNS server for your network, you can direct the 
Configure DNS Server wizard to update its root hints from an existing DNS server on 
the network. 


W If you do not have other DNS servers on your network but still need to resolve Internet 
DNS names, you can use the default root hints file, which includes a list of Internet root 
servers authoritative for the Internet DNS namespace. 


Possible cause #5: The DNS server does not have network connectivity to the root servers. 
Solution #5: Test for connectivity to the root servers. 


If root hints appear to be configured correctly, verify that the DNS server used in a failed 
query can ping its root servers by IP address. If a ping attempt to one root server fails, it might 
indicate that an IP address for that root server has changed. Reconfiguration of root servers is 
not very common. A more likely cause is a loss of network connectivity or, in some cases, poor 
network performance on your intermediate network links between the DNS server and its con- 
figured root servers. 


By default, the DNS service uses a recursive timeout of 15 seconds before failing a recursive 
query. Under normal network conditions, this timeout does not need to be changed. If perform- 
ance warrants it, however, you can increase this value. 
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Troubleshooting Dynamic Updates 


Specific Error #1: The DNS Client Is Not Performing Dynamic 
Updates 


Possible cause #1: The client or its DHCP server does not support the use of the DNS 
dynamic update protocol. 


Solution #1: Verify that your clients or servers support the DNS dynamic update protocol 
using the options for dynamic update support provided in Windows 2000. 


For client computers to be registered and updated dynamically with a DNS server, either 


@ Install or upgrade client computers to Windows 2000. 


Æ Install and use a Windows 2000 DHCP server on your network to lease client 
computers. 


By default, computers running any version of Windows 2000 attempt to register and perform 
dynamic update of their DNS names and IP addresses with a DNS server. For computers not 
running Windows 2000, you can deploy Windows 2000 DHCP servers, which can perform prox- 
ied registrations and updates as needed for nondynamic clients. 


Possible cause #2: The client was not able to register and update with the DNS server 
because of missing or incomplete DNS configuration. 


Solution #2: Verify that the client is fully and correctly configured for DNS, and update its 
configuration as needed. 


A common cause of the client failing to update with the DNS server is that it does not have a 
DNS suffix configured. This can result in the client attempting to register an incorrect or 
unintended DNS domain name. The client could be attempting to register its unqualified com- 
puter or hostname as a top-level domain name in the root zone. This happens because without 
a DNS suffix configured for the client computer, Windows 2000 believes the configured short 
name of a computer is its fully qualified domain name. This occurs only when the computer 
name does not have a DNS suffix to append to it and qualify the computer name when regis- 
tering it for the client in DNS. 


To update the DNS configuration for a client, you can either: 


E Configure a primary DNS suffix at the client computer for static TCP/IP clients. 


Æ Configure a connection-specific DNS suffix for use at one of the installed network con- 
nections at the client computer. 


Possible cause #3: The DNS client attempted to update its information with the DNS server 
but failed because of a problem related to the server. 
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Solution #3: At the Windows 2000 client computers, you can use Event Viewer to check the 
System log for any event messages that explain why attempts by the client to dynamically 
update its host (A) or pointer (PTR) resource records failed. When reviewing messages in the 
System log, filter or order the display of all messages to view those that specify DnsApi as the 
message source. Typically, these messages are related to the performance of DNS activities, 
such as DNS queries or dynamic updates. 


A common reason updates might fail for a mobile client is that the DNS server required to 
accept and perform the update does not respond when the client starts at a remote location on 
the network. This could be due to network performance issues or might indicate a problem in 
the underlying design of your network. Where these issues seem likely, you should review your 
DNS deployment and modify it accordingly. 


Specific Error #2: The Server Is Not Performing Dynamic Updates 
Possible cause #1: The DNS server does not support dynamic updates. 


Solution #1: Verify that the DNS server used by the client can support the DNS dynamic 
update protocol, as described in RFC 2136. For Windows DNS servers, only Windows 2000 
DNS servers support dynamic updates. The DNS server provided with Windows NT Server 4.0 
does not. If you are using other DNS servers on your network, verify that they are running a 
DNS server implementation that supports dynamic updates (BIND 8.1.2). 


Possible cause #2: The DNS server supports dynamic updates but is not configured to accept 
them. 


Solution #2: Verify that the primary zone where clients require updates is configured to allow 
dynamic updates. For Windows 2000 DNS servers, the default for a new primary zone is to not 
accept dynamic updates. Modify zone properties to allow updates at the DNS server that loads 
the applicable primary zone. 


Possible cause #3: The zone database is not available. 


Solution #3: Verify that the zone is available for update. First verify that the zone exists. For 
a standard primary zone, verify that the zone file exists at the server and that it is not 
paused. If you are using Active Directory—integrated zones, verify that the DNS server is run- 
ning on a domain controller and has access to the Active Directory database where zone data 
is stored. 


Secondary zones do not support dynamic updates. If you are trying to determine which server 
is the primary server for a standard zone, review zone authority records to determine which 
server is referenced in both the start of authority (SOA) and name server (NS) resource 
records for the zone. 
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If you need to, you can use the DNS console to change a secondary zone to become a primary 
zone so that it can accommodate dynamic updates. However, because standard primary zones 
use a single-master update model, you can configure only one server to accept dynamic 
updates for the zone. If you change the zone type at a secondary server so that it becomes the 
primary server for that zone, you need to either remove the zone or convert it to another zone 
type, such as a secondary zone, at the original primary server. Otherwise, zone data would 
become inconsistent and cause additional problems. 


If you want to have more than one DNS server be able to update a zone, it is reeommended 
that you change the zone type so that it becomes Active Directory—integrated. To be able to use 
this zone type, Active Directory must be installed and the server computer must be promoted 
to a domain controller. After the zone is integrated and stored in the directory, other domain 
controllers can load the zone automatically and be allowed to update it when they are 
installed as Windows 2000 DNS servers. 


Possible cause #4: The DNS server is configured to allow only secure dynamic updates and 
has a security-related problem. 


Solution #4: Verify that zone or resource record security is not in effect that might block or 
prevent dynamic updates at the server. Secure update can be enabled for directory-integrated 
zones as discussed earlier in this chapter. If secure dynamic update is in effect, current zone or 
resource record security might block or prevent a DNS client or its DHCP server from per- 
forming an update of its host (A) and pointer (PTR) resource records. In most cases, secure 
dynamic update does not prevent new records from being created or added to a zone, but it 
does restrict who is given default permissions to update or modify records. 


Troubleshooting DNS Zones 
Specific Error #1: Problems Related Specifically to Zone Transfers 


Possible cause #1: The DNS Server service is stopped or the zone is paused. 


Solution #1: Verify that the master (source) and secondary (destination) DNS servers 
involved in completing transfer of the zone are both started and that the zone is not paused at 
either server. 


Possible cause #2: The DNS servers used during a transfer do not have network connectivity 
with each other. 


Solution #2: Eliminate the possibility of a basic network connectivity problem between the 
two servers. Use the ping command to establish basic layer 3 network connectivity between 
the two DNS servers. 


Possible cause #3: The serial number is the same at both the source and destination servers. 
Because the value is the same at both servers, no zone transfer occurs between the servers. 
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Solution #3: Using the DNS console, perform the following tasks: 


WE Increase the value of the serial number for the zone at the master server (source) to a 
number greater than the value at the applicable secondary server (destination). 


W After you have increased the serial number at the master server to a higher value than 
is used currently at the secondary server, you should be able to initiate zone transfer at 
the secondary server. 


When working within the DNS console, the zone serial number can be viewed from the Start 
of Authority (SOA) tab in the applicable zone properties. To increase this number in the zone, 
click Increment. 


Possible cause #4: The zone has resource records or other data that cannot be interpreted by 
the DNS server. 


Solution #4: Verify that the zone does not contain incompatible data, such as unsupported 
resource records types or data errors. In most cases, the DNS Server service supports all 
resource record (RR) types that are approved and required for Internet standard DNS usage. 


Also, verify that the server has not been configured in advance to prevent loading a zone when 
bad data is found. In addition, check the server’s method for checking names. Use the DNS 
console to configure these settings. 


Possible cause #5: Authoritative zone data is incorrect. 


Solution #5: If a zone transfer continues to fail, ensure that the zone does not contain non- 
standard data. If you manually edit zone files, be aware that records need to be formatted and 
used according to standard record usage and formatting guidelines as specified in the RFCs 
for DNS. In most cases, user input and data errors can be avoided if records are added and 
managed using the DNS console. 


To determine whether incorrect zone data is a likely source for a failed zone transfer, look in 
the DNS server event log for messages. You can also use the nslookup command with the -1s 
option to simulate and test a zone transfer. 


Specific Error #2: Trying to Use a Zone Delegation Fails 


Possible cause: Zone delegations are not configured correctly. 


Solution: Review how zone delegations are used and revise your zone configurations as 
needed. Zones contain information about DNS domains and subdomains. For each new zone 
you create, the zone originally begins as a single-node database for one DNS domain. As 
needed, new subdomain nodes can be added directly below the original or parent domain and 
stored as a single zone. When new subdomains remain part of the same zone, they sometimes 
are called subzones. If used as subzones, new subdomains are retained as part of the zone and 
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replicated and updated along with it as a single entity. You can, however, delegate subdomains 
away and manage them in their own zones. For each subdomain delegated to its own zone, the 
parent zone needs to have delegation records added to it. 


With Windows 2000 DNS servers, you can use the New Delegation Wizard provided in the 
DNS console to simplify adding these records. 


Interoperability Problems 


The Windows 2000 DNS service supports and implements some Request for Comment (RFC) 
draft specifications used to define DNS usage for the Internet. It also adds design support for 
most approved RFCs that form the current DNS protocol standard. These features provide the 
means for operating Windows DNS servers in mixed or heterogeneous environments that are 
so critical in our networks today. 


The primary benefits for interoperability in these environments include the following: 


Æ Full interoperability with other DNS server implementations that implement RFC- 
compliant behavior for DNS name service 


E Use of Windows DNS servers to provide DNS service on the Internet 


For interoperability testing, Microsoft has tested the Windows 2000 DNS Server service with 
the following versions of the Berkeley Internet Name Domain (BIND) DNS server implemen- 
tation: 


@ BIND 4.9.7 
E BIND 8.1.2 
E BIND 8.2 


Interoperability and configuration issues related to using Windows 2000 DNS with other envi- 
ronments, or when using DNS servers on the Internet, are covered in the following sections. 


Zone Transfer with BIND and Other DNS Server 
Implementations 


When transferring a zone between two Windows DNS servers, the DNS Server service always 
uses a fast transfer method that uses compression. This method includes multiple resource 
records (RRs) in each message sent to complete the transfer of the zone between servers. For 
Windows 2000 DNS servers, this is the default method used when initiating transfer with 
other DNS server implementations. If necessary, Windows 2000 DNS servers can be config- 
ured to transfer a zone using the slower uncompressed transfer format. This enables success- 
ful zone transfers to be made with DNS servers that do not support the faster transfer 
method, such as BIND servers prior to version 4.9.4. When the Bind Secondaries option in 
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advanced server properties is checked, no fast transfers are made. By default, the check box is 
cleared to enable fast transfers. 


Supporting Active Directory with Other DNS Server 
Implementations 


In many large organizations, DNS is already implemented using other solutions, such as 
UNIX DNS servers that run legacy versions of BIND software. In some cases, these DNS 
servers are not equipped to support the DNS requirements for deploying Active Directory. 


This issue can be addressed in one of two ways: 


E Upgrade any BIND DNS servers to version 8.1.2 or later of the BIND software to meet 
the DNS requirements for Active Directory support. 


HM Use the DNS service provided with Windows 2000 Server to migrate any of your current 
DNS zones to Windows 2000 DNS servers. 


Although the DNS service is recommended to support Active Directory, you can use other DNS 
server implementations for this purpose. These other implementations should support the fol- 
lowing standard specifications: 


W The use of service location (SRV) resource records, as described in the Internet-Draft, “A 
DNS RR for specifying the location of services (DNS SRV)” 


E Dynamic updates in DNS, as described in RFC 2136 


Support for dynamic updates is recommended but not essential. Support for the SRV resource 
record is mandatory because it is required to provide basic DNS support to Active Directory. A 
DNS server, such as Windows NT Server 4.0 with Service Pack 4 and later, does not support 
dynamic updates. It does, however, support DNS requirements of Active Directory because 
SRV resource record support was added with Service Pack 4. Additional manual administra- 
tion of SRV resource records is needed for DNS configuration support of Active Directory to 
function properly on a DNS server that does not support dynamic updates. This manual 
administration introduces the increased possibility of human error. 


Interoperating Windows DNS Servers with Other DNS 
Server Implementations 
You may decide to use and manage a Windows 2000 DNS service with a Bind DNS configura- 
tion if 
Æ Existing DNS servers for root zones are not to be upgraded or migrated to other DNS 
solutions. 


HM The DNS service and Windows 2000 Server are to be deployed and provide management 
of any DNS domain names required to register, update, and support for use with Active 
Directory. 
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You can modify your DNS namespace design plans in a couple of ways. First, you can create 

a single new subdomain in your current DNS domain namespace to root your first Active 
Directory domain. If your organization has registered and is using a second-level domain 
name, such as Que.com, you can create a single subdomain such as Northamerica.Que.com 
and use this domain to root the DNS domain namespace used by Active Directory. The DNS 
service is automatically configured to support Active Directory when you install the first 
domain controller. Before you have created a zone for the new subdomain at a computer run- 
ning the DNS Server service, you can delegate these subdomains away at the primary zone for 
your second-level domain. In some cases, you might need only to notify another DNS or UNIX 
system administrator in your organization to make this delegation for you. 


Secondly, you can create multiple subdomains based on your DNS second-level domain to sup- 
port registration of Active Directory in DNS. For example, if your organization has a regis- 
tered second-level DNS domain name already in use, you can create additional subdomains 
that are delegated to Windows DNS servers and used only for registering DNS names related 
to Active Directory. This method is more complex to implement, but enables less change to 
your currently deployed DNS infrastructure that is not Windows-based. With this namespace 
design, you create only those additional subdomains and appropriate zones needed to support 
your Active Directory deployment. For example, in this configuration, the domain name 
Que.com is both the root DNS and the root Active Directory domain name for your organiza- 
tion. 


For this configuration, you first need to create zones for the following subdomains using the 
DNS snap-in tool at a computer running DNS service and Windows 2000 Server: 


_Mmsdcs.que.com 
_idap._tcp.que.com 


Before these zones are created, you can delegate these subdomains away at the primary zone 
for your parent or second-level domain name. You might have to notify another DNS adminis- 
trator to manage these zones for you if your organization doesn’t have direct control on the 
DNS servers. 


Using DNS on the Internet 


To establish a presence on the Internet, an individual or business must first apply for and reg- 
ister a second-level domain name with an authorized DNS domain name registration author- 
ity. Your Internet service provider (ISP) can often perform this function and obtain a name on 
your behalf for an additional fee. 


To register your domain name, there are several required tasks. One of these is selecting and 
researching a second-level domain name that is not currently registered or in use. This can be 
done if you have Internet access by using a WHOIS query engine provided at the Web site for 
your applicable Internet DNS domain name registrar. Be prepared to select an alternate name 
if your WHOIS query indicates that your preferred selection is already registered and in use. 
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Another required task is registering and obtaining at least one IP address valid for use on the 
Internet. This address is needed for the DNS server on the Internet that you want to establish 
as the host for the primary copy of the zone based on your second-level domain name. In many 
cases, if you are using an ISP to register a domain name on your behalf, it can specify the IP 
addresses for one or two of its servers as primary and secondary for the Internet. 


As part of the registration process, an applicant must provide at least two currently active 
DNS servers that are used on the Internet as the primary and secondary servers designated 
for the new domain. This requirement is to ensure proper Internet root server configuration 
and referral for others that query your registered DNS domain name on the Internet. 


After one IP address has been obtained, you or your ISP can arrange to use another company’s 
or ISP’s DNS server as a secondary server for the zone. If you still need to obtain an IP 
address directly for use in the United States, a valid IP address can be obtained through the 
American Registry for Internet Numbers (ARIN). In other countries, you might contact your 
local Internet service or telephony provider to find out how to register and acquire an IP 
address if one is needed. 


Next, complete the registration application form and submit it with your registration fee to 
the appropriate Internet DNS domain name registration authority. Registrations are typically 
valid for a specific period of time and must be periodically renewed. 


Interoperability Planning: Configuring Related Services 


Windows 2000 Server provides several interoperability options when using the DNS service 
with other TCP/IP services. In many cases, you can use these features to reduce the amount of 
time you need to spend administering your DNS namespace and provide an improved naming 
service for your network. These options most often include use of WINS forward and reverse 
lookups. 


In Windows NT Server 4.0, Windows 2000, or later, the DNS service provides for the use of 
WINS lookup. This feature enables configured DNS zones to refer queries not answered from 
current zone information to a WINS server for further resolution. With this added search of 
the WINS namespace, both DNS and WINS are used to complete a full search of registered 
names for a matched response. 


WINS lookup is supported for both forward and reverse lookup zones and can be enabled on a 
per-zone basis or configured for selected zones. This feature should also be configured to pre- 
vent replication or zone transfer of WINS resource records to servers with other DNS imple- 
mentations that do not recognize the WINS resource records. 


COMMAND-LINE 
UTILITIES 


This appendix will give a brief overview of some of the command-line utili- 
- ties that can be used to configure and troubleshoot DNS. 


Troubleshooting and Configuring DNS 
Through Command-Line Tools 


The nslookup command is a familiar command from previous versions of 
DNS. There are also some new commands that work with the Windows 
2000 DNS server. In this section, we describe some of the common 
command-line tools used to troubleshoot DNS. 


nslookup Command 


The nslookup command is a part the TCP/IP suite of protocols and therefore 
a part of almost all implementations of DNS. Because this book is targeted 
for an advanced audience and many of the nslookup commands have been 
covered in the text, we will focus on some of the commands that are less 
often used, but still have value for troubleshooting DNS. 


Verifying DNS Server Responsiveness Using nslookup 


From the command prompt, type nslookup server_IP_address 127.0.0.1. The 
server_IP_address is the TCP/IP address of the DNS server from which you 
want to test responsiveness. 
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For example: nslookup 192.168.0.1 127.0.0.1 


This should return the following information: 


Server: localhost 

Address: 127.0.0.1 

Name: workhorse.pelicancreek.home.bobcollier.org 
Address: 192.168.0.1 


The return of this information is an indication that the DNS server is functioning and accept- 
ing queries. 


Verifying DNS Registrations for Domain Controllers Using nslookup 


From the command prompt, type nslookup. Once at the nslookup prompt, type set 
querytype=resource record_type. Resource record_type is the resource record type that you want 
to verify—in this case, SRV resource records. Now type a query for the service that you want 
to verify: Kerberos. _tcp.dc._mcdcs.active directory domain name. If the return query is suc- 
cessful, you can view the information and determine whether all the domain controllers in 
your organization are listed. 


The following is an example of command-line output for an nslookup session, used to verify 
service location (SRV) resource records that are registered by Windows 2000 domain con- 
trollers. In this example, there are two domain controllers for the Active Directory domain 
pelicancreek.home.bobcollier.org: workhorse and testw2k. 


Type nslookup, click Enter 
Default Server: workhorse.pelicancreek.home.bobcollier.org 
Address: 192.168.0.1 
Type set querytype=srv, click Enter 
Type: 
_kerberos. tcp.dc._mcdcs.pelicancreek.home.bobcollier.org 
click Enter to receive the following information: 
Server: workhorse.pelicancreek.home.bobcollier.org 
Address: 192.168.0.1 
_kerberos. tcp.dc. mcdcs.pelicancreek.home.bobcollier.org SRV service location: 
priority =0 


weight =100 
port =88 
svr hostname =workhorse.pelicancreek.home.bobcollier.org 


_kerberos. tcp.dc._mcdcs.pelicancreek.home.bobcollier.org SRV service location: 
priority = 


weight =110 
port =88 
svr hostname = workhorse. pelicancreek.home.bobcollier.org 


workhorse. pelicancreek.home.bobcollier.org internet address = 192.168.0.1 
workhorse.pelicancreek.home.bobcollier.org internet address = 192.168.0.10 


Troubleshooting and Configuring DNS Through Command-Line Tools 245 


If the query fails, then you need to reconfigure the SRV resource records or reload them using 
the net logon command. Use of the net logon command will be covered later in this appendix. 


Identifying WINS Versus DNS Authoritative Query Responses 
Using nslookup 


If you need to determine whether a response came from a DNS server or a WINS server, you 
can use nslookup to verify whether the response to a DNS query was resolved through DNS or 
through WINS. From a command prompt, type nslookup and press Enter. 


Once at the nslookup prompt, type set debug and press Enter. This option is required to view 
query response information about whether the response is authoritative or nonauthoritative. 
Authoritative responses will come from a DNS zone database or a WINS server. The nonau- 

thoritative responses come from cached data. 


You can do forward lookups or reverse lookups, depending on what information you are look- 
ing for, by typing one of the following commands: 


Set querytype=a - for forward lookups or 
Set querytype=ptr - for reverse lookups 


Then, press Enter. 


If you are performing a forward lookup, type the fully qualified domain name of the host you 
are querying. If you are performing a reverse lookup, type the TCP/IP address of the host you 
are looking for. 


The following example shows a forward lookup for a host named 
mustang.pelicancreek.home.bobcollier.org. 


Type nslookup, press Enter. 

Type set debug, press Enter. 

Type set querytype=a, press Enter. 

Type mustang.pelicancreek.home.bobcollier.org (FQDN), press Enter. 


The return information is as follows: 


Server: workhorse. pelicancreek.home.bobcollier.org 
Address: 192.168.0.1 
Got answer: 
HEADER: 
Opcode = QUERY, id = 2, rcode = NXDOMAIN 
header flags: response, auth. answer, want recursion, recursion avail. 
questions = 1, answers = @, authority records = 1, additional = 0 
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QUESTIONS: 


mustang.pelicancreek.home.bobcollier.org.pelicancreek.home.bobcollier.org, type = A, class 


AUTHORITY RECORDS: 


-> pelicancreek.home.bobcollier.org 
ttl = 3600 (1 hour) 
primary name server = workhorse.pelicancreek.home.bobcollier.org 
responsible mail addr = admin 
serial = 12704 
refresh = 900 (15 min) 
retry = 600 (10 min) 
expire = 86400 (1 day) 
default TTL = 3600 (1 hour) 
Got answer: 
HEADER: 
Opcode = QUERY, id = 3, rcode = NXDOMAIN 
header flags: response, auth. answer, want recursion, recursion avail. 
questions = 1, answers = @, authority records = 1, additional = @ 
QUESTIONS: 


mustang.pelicancreek.home.bobcollier.org.home.bobcollier.org, type = A, class = IN 
AUTHORITY RECORDS: 


-> 


home.bobcollier.org 
ttl = 3600 (1 hour) 
primary name server = workhorse.pelicancreek.home.bobcollier.org 
responsible mail addr = administrator 
serial = 209 
refresh = 900 (15 min) 
retry = 600 (10 min) 
expire = 86400 (1 day) 
default TTL = 3600 (1 hour) 


Got answer: 
HEADER: 


Opcode = QUERY, id = 4, rcode = NXDOMAIN 
header flags: response, auth. answer, want recursion. Recursion avail. 
questions = 1, answers = @, authority records = 1, additional = @ 


QUESTIONS: 


mustang.pelicancreek.home.bobcollier.org.bobcollier.org, type = A, class = IN 


AUTHORITY RECORDS: 


-> 


CE 


(root) 
ttl = 3600 (1 hour) 
primary name server = workhorse.pelicancreek.home.bobcollier.org 
responsible mail addr = administrator 
serial = 5 
refresh = 900 (15 min) 
retry = 600 (10 min) 
expire = 86400 (1 day) 
default TTL = 3600 (1 hour) 


me ee 


= 
= 


IN 
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Got answer: 
HEADER: 
Opcode = QUERY, id = 5, rcode = NOERROR 
header flags: response, auth. answer, want recursion, recursion avail. 
questions = 1, answers = 1, authority records = 0, additional = 0 
QUESTIONS: 
mustang.pelicancreek.home.bobcollier.org, type = A, class = IN 
ANSWERS: 
-> Mustang.pelicancreek.home.bobcollier.org.bobcollier.org 
internet address = 192.168.0.21 
ttl = 1200 (20 min) 


This query response tells us that this was an authoritative response, which means that it was 
resolved through a DNS authoritative server or through a WINS server. To determine whether 
this is through DNS or through WINS, take notice of the ttl for the record. Repeat the query; 
if the ttl for the resource record is less than the previous attempt, then it was resolved 
through WINS. If the ttl remains the same, then it is being resolved through an authoritative 
DNS server. 


Notice in the example that there where three authoritative lookups: 


Mi pelicancreek.home.bobcollier.org (subdomain of a child domain) 
Mi home.bobcollier.org (child domain) 
W bobcollier.org (top-level domain) 


This happens because recursion is enabled on the DNS server. 


Using ipconfig to Troubleshoot DNS 


The ipconfig command-line utility has many new features and functionality in Windows 2000 
DNS infrastructure. We will discuss some of the new features added to ipconfig as they relate 
to DNS. 


Renew DNS Client Registrations Using ipconfig Utility 


To manually register hostnames and TCP/IP addresses to DNS, Windows 2000 clients can use 
the ipconfig /registerdns command. This option can greatly assist in troubleshooting failed 
DNS name registration or in resolving a dynamic update problem between a client and the 
DNS server. This command refreshes all DHCP address leases and registers all related DNS 
names used by the client. 


When troubleshooting failed client dynamic DNS registrations, it is helpful to verify that the 
cause is not caused by one of the following common causes for failures: 


E The DNS zone in which the client is attempting to register is not configured or able to 
accept dynamic updates. 
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E The primary DNS server refused the update request. This can be caused if the client 
does not have the appropriate security access rights to update their resource records. 


M The server or zone is not available for some reason. 


E There are other network problems preventing communication between the client and the 
DNS server. 


To manually register or update host resource records in DNS, from the command prompt type 
ipconfig /registerdns and press Enter. 


The resulting message would read 


Registration of the DNS resource records for all adapters of this computer 
has been initiated. Any errors will be reported in the Event Viewer in 
15 minutes 


You can check the DNS server to ensure that the record has been updated and check the 
clients Event Viewer (system log) to see what, if any, errors were encountered. 


Display and Review Client Resolver Cache Using ipconfig 
Command Utility 
To view the contents of the DNS client resolver cache, including entries preloaded from the 


local HOSTS file, the ipconfig /displaydns command is used. The DNS client resolver cache is 
used to quickly resolve frequently queried names before it queries the DNS server. 


The resolver cache also supports negative caching or unresolved or invalid DNS names. These 
entries are added to the DNS client resolver cache so that it is not queried again. This saves 
on query performance. 


This example of the ipconfig /displaydns command will describe the results of one client’s 
DNS resolver cache. There are entries from a host file, resolved through DNS, and negative 
cached entries. 


From the command prompt, type ipconfig /displaydns, and press Enter. 


The result from my client looks like this: 


Oldpc. [from HOSTS file] 
Record Name... ... . : Oldpce 
Record Type. ...»...4: 1 
Time to Live .....-. : 31406507 
Data Length. ......, : 4 
Section . . wires de Hee vant : Answer 


A (host) Record.....: 
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localhost. [from HOSTS file] 


ee ee ed 


Record Name... . . . . : localhost 
Record Type .......: 1 
Time to Live .... . « : 31406507 
Data Length. ...... : 4 
Section. ..... .. . i Answer 
A (host) Record. . . i 
127.0.0.1 
workhorse. [from DNS resolution to two adapters] 
Record Name... . . . . : workhorse.pelicancreek.home.bobcollier.org 
Record Type . s.a.a aa i] 
Time to Live ...... : 3191 
Data Length.......:4 
Section... s a a. . . I Answer 
A (host) Record . E E- 
192.168.0.1 
Record Name . . . . » | workhorse.pelicancreek.home.bobcollier.org 
Record Type a aasa 27 
Time to Live ...... : $191 
Data Length ....... : 4 
Section... .... . . : Answer 


A (host) Record . a a 
209 .99.125.182 
bubba. [from failed resolution] 

Negative cache entry for name error 
1.0.0.127.in-addr.arpa. 


Ce ee ey 


Record Name. .... . . ! 1.0.0.127.in-addr.arpa 
Record Type. ...... : 12 

Time to Live .... . . : 31406507 

Data Length.......: 4 

Section... ... . . . 1 Answer 


A (host) Record . a 
localhost 
1.0.0.10.in-addr.arpa. 


ee ee ee ee ey 


Record Name. ..... . : 1.0.0.10.in-addr.arpa 
Record Type ....... : 12 

Time to Live . . . . . . : 31406507 

Data Length . ......:4 

Section. ....... . : Answer 


A (host) Record..... 
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Flush and Reset a DNS Client Resolver Cache Using ipconfig 
Command Utility 


To flush and reset the DNS client resolver cache, the ipconfig /flushdns command is used. 
During DNS troubleshooting, this process can be used to discard any negative cache entries or 
dynamically added entries from the DNS client resolver cache. Entries that were preloaded 
from the HOSTS file will not be flushed. To remove these entries, you will need to remove 
them from the client’s HOSTS file. 


To flush the DNS client resolver cache, from the command prompt, type ipconfig /flushdns, 
and press Enter. 


The resulting response is 


Successfully Flushed the DNS Resolver Cache 


To verify that the cache has been successfully flushed, type ipconfig /displaydns. The only 
entries that should show up are those, if any, that were preloaded from the client’s HOSTS 
file. 


In my previous example, the records that show up after flushing the DNS client resolver 
cache are 


Oldpc [from HOSTS file] 
Record Name... ... . : Oldpe 
Record Type .......: 14 
Time to Live .... . . ! 31406507 
Data Length. ......:4 
Section... ..... . I Answer 
A (host) Record.....: 

10.0.0.1 


localhost. [from HOSTS file] 


=... =- eee ew ewe eee eee ee he he ee ew eh uuum a Mm M n ww 


Record Name... . a. . . ! localhost 
Record Type .......: 1 
Time to Live ...... : 31406507 
Data Length. ......:4 
Section... ... .. . © Answer 
A (host) Record.....: 

127.0.0.1 


1.0.0.127.in-addr.arpa. 


=.. = s= eee eee eee see ewe wwe wuu yu u a umapa nan amuue w m w w m mom o 


Record Name .. .... . ! 1,0.0.127.in-addr.arpa 
Record Type ...... 112 
Time to Live . . . . . . : 31406507 


Data Length .. saas’ 14 
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localhost 
1.0.0.10.in-addr.arpa. 


ay 


Record Name... .. . . : 1.0.0.10.in-addr.arpa 
Record Type. ...... : 12 
Time to Live . . . . . . : 31406507 
Data Length . s.a.a : 4 
Section . aoao’ . . 1 Answer 
A (host) Record... . i 
Oldpc 


Notice that only the records from the HOSTS file are still listed in the DNS client resolver 
cache. 


Using dnscmd from the Command Line to Manage Your 
DNS Servers 


The dnscmd command-line utility is provided to manage DNS servers and can be used to script 
batch files, automate management, and update functions of existing DNS server configura- 
tions and used to perform setup and configuration of a new DNS server. 


This command-line utility is installed by copying it from the \support\enterprise\reskit folder 
on the product CD. For complete documentation, see the Windows 2000 resource kit. 


For basic help using the command-line utility, from a command prompt type dnsemd /?. This 
will return the following syntax: 


USAGE: DnsCmd <ServerName> <Command> [<Command Parameters>] 


<ServerName>: 

i - local machine using LPC 

IP address - RPC over TCP/IP 

DNS name -- RPC over TCP/IP 

other server name -- RPC over named pipes 

<Command>: 

/Info -- Get server or zone information 

/ResetRegistry -- Reset server or zone registry properties 
/Statistics -- Query/clear server statistics data 

/Restart -- Restart DNS server 

/DebugBreak -- Server debug break (internal) 

/ClearCache -- Clear DNS server cache 

/UpdateServerFile -- Write back all zone or root-hint datafile(s) 
/ResetListenAddresses -- select server IP address(es) to serve DNS requests 
/ResetForwarders -- set IP address(es) to forward unsolvable queries 
/EnumZones - Enumerate zones 

/ZoneAdd -- Create a new zone on the DNS server 

/ZoneDelete -- Delete a zone from DNS server or DS 


/ZonePause -- Pause a zone 
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/ZoneResume -- Resume a zone 

/ZoneReload -- Reload zone from its database (file or DS) 
/ZoneWriteBack -- Write back zone to file 

/ZoneRefresh -- Force refresh of secondary zone from master 
/ZoneUpdateFromDs -- Update a DS integrated zone by data from DS 
/ZoneResetType -- Change zone type Primary/Secondary/DSintegrated 
/ZoneResetSecondaries -- Set notify list for a zone 

/EnumRecords -- Enumerate records at a name 

/RecordAdd -- Create a record in zone or RootHints 
/RecordDelete -- Delete a record from zone, RootHints or Cache data 
/NodeDelete -- Delete all records at a name 

/SbsRegister -- SBS Registration 

/SbsDeleteRecord -- SBS Record Delete 


<Command Parameters>: 
According to each Command 
1? -- help info for each Command 


Using Netlogon from the Command Prompt to 
Manage DNS 


The netlogon service in Windows 2000 uses new DNS server support to provide registrations 
of domain controllers in your DNS domain namespace. Active Directory has a dependency on 
DNS, for registering and resolving domain controllers. If you do not install the DNS server 
provided with Windows 2000, a file called Netlogon.dns is written and created during the 
Active Directory installation process. This file contains the SRV resource records needed to 
support the use of Active Directory. The file is created in the %systemroot% \system32 \config 
folder. 


In a Windows 2000 implementation of DNS and Active Directory, the netlogon service from a 
domain controller registers one or more SRV resource records. Netlogon can register any or all 
of the following SRV resource records: 


_idap._tcp.<DNS Domain_Name> 
_ldap._tcp.<Site_name>._sites.<DNS Domain_Name> 
_idap._tcep.dc._msdcs.<DNS Domain_Name> 
_idap._tep<Site_name>. sites.dc. msdcs.<DNS Domain_Name> 
_idap._tep.pde._msdcs.<DNS Domain_Name> 
_ldap._tcp.gc._msdcs.<DNS Forest_Name> 
_idap._tcp.<Site_name>. sites.gc. msdcs.<DNS Forest_Name> 
_gc._tcep.<DNS Forest_Name> 
_gc. _tcp.<Site_name>.sites.<DNS Forest_Name> 

_ildap._tcp.<Domain_Guid>.domains. msdcs.<DNS Forest_Name> 
_Kerberos. tcp.<DNS Domain_Name> 

_Kerberos. udp.<DNS Domain_Name> 

_Kerberos._tcp.<Site_name>. sites.<DNS Domain_Name> 

_Kerberos._tcp.dc._msdcs.<DNS Domain _Name> 

_Kerberos. tcp.<Site_name>. sites.dc._ msdcs.<DNS Domain _Name> 
_kKpasswd._tcp.<DNS Domain _Name> 
_kpaswd._udp.<DNS Domain _Name> 
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Netlogon also registers the following DNS A resource records: 


<DNS_Domain_Name> 
_gc._msdcs.<DNS_Forest_Name> 


Netlogon also registers the following DNS CNAME resource records: 


<DsaGuid>._ msdcs.<DNS Forest_Name> 


The netlogon service attempts to validate the names registered by other domain controllers in 
the domain. From the command prompt, you can manually update the registration of SRV 
resource records for a domain controller by performing the following commands: 


From the command prompt, type net stop netlogon, and press Enter. This stops the netlogon 
service. 


After the service has been stopped, type net start netlogon, and press Enter. This restarts the 
netlogon service and registers all the SRV resource records for the domain controller with 
DNS. Using this command, you can refresh or update DNS with the current configuration of 
services for a domain controller. This is especially useful when adding new services to a 
domain controller and not wanting to reboot the machine. 


_ Using Services Applet to Start/Stop Netlogon 
As with all services, the netlogon service also can be stopped and started from the services applet under Administrative Tools. 


This appendix has provided several command-line utilities that can be used to configure, man- 
age, automate tasks, and troubleshoot DNS. For additional information on these utilities, con- 
sult the online help through the DNS help or through the Windows 2000 resource kit. Tech 
Net and Microsoft’s knowledge base articles will also provide insightful information. 


GLOSSARY 


A Records Host resource records are added to forward lookup zones and 
are used to resolve names (host, FQDN, domain) to IP addresses. 


Access Control List (ACL) A table that is associated with an object or 
resource that defines what access rights users or objects have when access- 
ing the object or resource. 


Active Directory The directory service provided with Windows 2000 
Server that provides object-oriented data store used for defining objects in a 
Windows 2000 network. 


Active Directory Integrated Zone A DNS zone that is stored as part 
of a Windows 2000 Active Directory rather than as a text-based file on the 
DNS server. Active Directory Integrated zones can be multiple zones, and 
updates and zone transfers occur as part of the Active Directory replication 
process. 


ARPAnet United States government-sponsored network that connected 
the military, government, university, and government contractors. The 
ARPAnet is now known as the Internet. 


Authoritative When referring to zones in DNS servers, a zone is said to 
be authoritative over a portion of the DNS namespace if the zone contains 
resource records for that portion of the namespace. 
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Best Current Practice (BCP) RFC This category of RFC specifies an Internet Best 
Current Practice for the Internet community, and is open for suggestions for improvement. 


Caching-Only Name Server A name server that does not host any zone databases, and 
does not respond to queries from other name servers, but does perform name resolution for 
client resolvers. 


Domain Any named node in the domain namespace. A domain name defines a people- 
friendly name for a point in the tree structure of the domain namespace. 


Domain Name System (DNS) Provides a named hierarchical structure to a network. The 
names used are computer hostnames and fully qualified domain names (FQDNs). The struc- 
ture that encompasses the domain name system is known as the domain namespace. 


Domain Namespace The hierarchical (or tree) structure created by the logical ordering of 
computer names on the Internet, and is structured in the same manner as the files and folders 
on a hard disk partition. 


Draft Standard RFC An RFC that has at least two independent and interoperable imple- 
mentations from different code bases developed. In other words, there have to be two different 
manifestations that can work together before draft standard is obtained. 


Dynamic Host Configuration Protocol (DHCP) Used with a DHCP server to dynami- 
cally lease a range on IP addresses to clients’ computers on a network. 


Experimental RFC This category of RFC is used to define an experimental protocol for the 

Internet community. It does not specify an Internet standard, but suggestions for improvement 
are welcome. These are typically part of a development or research effort, and are published to 
provide general information and as an archive of the work performed. 


Forward Lookup Zone A zone file used by a DNS server to resolve a hostname or FQDN 
to its IP address. Standard primary and standard secondary zones are examples of forward 
lookup zones. 


Full Zone Transfer (AXFR) A zone transfer that sends the entire zone file during DNS 
server zone transfers. 


Fully Qualified Domain Name (FQDN) Describes a domain from the nearest node to the 
top of the domain name space, and uses periods to separate the domains crossed to reach the 
root. 


Historic RFC When an RFC standard becomes obsolete because a newer standard is intro- 
duced, the old RFC is changed to the Historic status. In this way, you can still review old stan- 
dards, but there is a pointer to the new standard that has taken the old standard’s place. 
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Hosts File A text-based file placed on a client computer that is used to resolve hostnames to 
IP addresses. 


in-addr.arpa Zone An in-addr.arpa zone is used for reverse lookup. That is, an IP address 
is provided and resolved to a name. Although reverse lookup zones are no longer used very 
often, you might need to create an in-addr.arpa zone to support reverse lookup queries. 


Incremental Zone Transfer (IXFR) A zone update that allows only the portion of a zone 
that is modified to be sent during DNS server zone transfers rather than the entire zone. 


Informational RFC (FYI) This category of RFC is used to provide information to the 
Internet community. It is intended to bring information to the Internet community in a timely 
manner, and is not part of a research and development effort. Many times, this type of docu- 
ment will help better explain an existing technology. 


Internet Architecture Board (IAB) Responsible for defining the Internet’s overall archi- 
tecture, provide guidance and direction to the IETF, and serve as a technology advisory group 
for the ISOC. 


Internet Assigned Numbers Authority (IANA) In charge of all unique parameters on the 
Internet, including domain names and IP addresses. 


Internet Engineering Steering Group (IESG) Provides technical management of IETF 
activities and the Internet standards process. Responsible for the movement along the 
Internet “standards track,” including final approval of Internet standards. 


Internet Engineering Task Force (IETF) Engineers and develops the protocols and stan- 
dards for the Internet. 


Internet Research Task Force (IRTF) Composed of a number of focused, small research 
groups that work on topics related to Internet protocols, applications, architecture, and tech- 
nology. These groups help promote the development of research collaboration and teamwork in 
exploring research issues. 


Internet Society (ISOC) Organization of Internet experts that comment on policies and 
practices, and oversee a variety of other organizations and task forces that help set Internet 
standards and policies. 


Internet Standard RFC Also called a Standard rather than Internet Standard, this is an 
RFC that has a high degree of technical maturity and significant implementation and opera- 
tional experience and provides significant benefit to the Internet community. 


Internet-Drafts A draft document created and submitted to the IETF. This document can 
later enter the RFC track and become an RFC. 


258 Appendix B Glossary 


IP Internet (IP) protocol. This is the current version of IP in use today. This version (version 
4) is based on a 32-bit IP address. 


IPV6 Version 6 of the Internet (IP) protocol is currently being tested, and will be in full use 
sometime during the later portion of this decade. IPV6 is based on a 128-bit IP address. 


Iterative Query A request, typically performed by a DNS name server, that requests the IP 
address (or best answer available) associated with a given computer name or domain name in 
the domain namespace. 


Master Name Server Any name server that hosts a primary or secondary copy of a zone 
database and also is responsible for sending updated copies of the database to other name 
servers. 


Microsoft Management Console (MMC) A single management tool used to support com- 
puters running the Windows 2000 operating system. 


Node A point in the hierarchical structure of the domain namespace. 


Primary Name Server A name server that maintains a zone database file. Any changes 
made to the zone are made to the primary zone database file, and then replicated to any sec- 
ondary name servers for that zone. 


Proposed Standard RFC This is the entry level for an RFC on the standards track, and is 
typically stable, well designed and understood, and, after review by the Internet community, is 
well received. 


PTR Records Pointer resource records are created in reverse lookup (in-addr.arpa) zones 
and are used to resolve IP addresses to hostnames. 


Recursive Query A request-the-resolver stub on client computer forms; it requests the IP 
address associated with a given computer name or domain name in the domain namespace. 
The response that can be provided to this type of query is absolute. 


Request For Comment (RFC) A document written and submitted to the IETF. This docu- 
ment can be informational in nature, or can offer a proposed networking standard. 


Resolver A program on a client computer that enables it to form queries for name resolu- 
tion by a DNS name server. A resolver is sometimes referred to as a resolver stub, because it is 
a small portion of a larger piece of software, such as the TCP/IP stack. 


Resource Record An entry into a DNS zone database file that provides information about 
a computer (which also is known as a host), network service, or domain in a zone. 


Reverse Lookup Zone A zone file used by a DNS server to resolve an IP address to a host- 
name. In-addr.arpa zones are an example of a reverse lookup zone. 
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Root Domain The top of the hierarchical (or tree) structure of the domain namespace. The 
root domain is represented by a period (.), which also is referred to as a dot. 


Secondary Name Server A name server that hosts a read-only copy of a zone database file. 
The secondary name server receives updates to the zones database file from the name server 
that is configured as the master name server. 


Service Location (SRV) Resource Records A type of DNS resource record that is used to 
identify services available on a network. Priority and weight also can be configured on the 
resource record to allow a DNS server to provide a particular resource record back from a 
query based on the settings used. 


Standard Primary Zone The read/write copy of the zone database. Changes made to the 
zone database must be made on the name server that contains the primary zone database. 


Standard Secondary Zone A read-only copy of the zone database. Changes made to the 
zone database are made on the name server that hosts the primary zone database file, and 
then using an update process, a name server hosting a secondary copy of the zone receives 
updates. 


Standard Track (STD) RFC A category of RFC specifies an Internet standards track pro- 
tocol for the Internet community and is open to suggestions for improvement. 


Start of Authority (SOA) resource record The first resource record in a zone, this record 
provides information about the administrator for the DNS server that hosts the zone, and 
operational parameters for the zone, such as the zone’s serial number and the TTL for zones 
information. 


Time To Live (TTL) A number added to a resource record that represents the amount of 
time (in seconds) that the name resolution information sent by a name server can be used by 
the client resolver or name server performing the query. 


Top-Level Domains The domains located just below the root domain in the domain name- 
space. There are a fixed number of top-level domains: COM, EDU, NET, GOV, MIL, NET, INT, 
and XX (two-character country code). 


Windows Internet Name Service (WINS) Provides a named flat structure to a Windows 
NT network. The names used are NetBIOS computer names. 


Zone A database that is stored on a DNS name server, which contains information about 
domains located in a contiguous portion of the domain namespace. 
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ACL, 213 
AD integrated, 51, 56 
adding, 52 


dynamic updates, 51 
full zone transfer (AXFR), 
51 


incremental zone transfer 
(IXF'R), 51 

primary, 51 

reverse lookup, 52, 70 

secondary, 51 

separating, 60 

troubleshooting, 236-238 

types, 51 

Windows NT 4.0, 51 

zone database files, 50 

zone transfers, 51 


DNS name servers 
AD, supporting, 239 
caching-only, 35, 38 
DHCP configuration options, 
updating, 128 
dnscmd command-line, 
managing, 251-252 
implementing, 200 
implementing multiple, 201 
iterative queries, 27 
listing, 37 
localized queries, testing, 217 
master, 35, 37 
primary, 36 


recursive queries, testing, 217 
resource records, TTL, 24-25 
tasks, 23 

verification, testing, 217 
zones, 23, 26 


DNS notify, 212 
configuring, 112-118 
process, 113-114 


DNS registrations (nslookup 
command), verifying, 
244-245 


DNS Server Configuration 
Wizard, root name server 
installation, 84-86 


DNS server event log 
events, configuring, 190 
severity, viewing, 189-190, 219 


DNS servers. See DNS name 
servers 


dnscache, 30 


dnscmd (DNS servers), 
managing, 221-222, 251-252 


dnscmd command-line utility, 
102 


DnsUpdateProxyGroup 
AD Manager, 142 
DHCP servers, adding, 216 


domain clients 
computers, 175 
users, 175 


domain controller servers, 
memory, 53 


domain controllers 

Active Directory, 34 

Active Directory Installation 
Wizard, creating, 178-179 

dcpromo.exe command, 
creating, 178 

DHCP servers, 142 

domains, 176 


Domain Name System. See 
DNS 


domain names 
AD (Active Directory) 
balancing internal / 
external access, 59 
previously registered 
domain names, 57 
private domain names, 
58-59 
selecting, 50, 57 
subdomains of registered 
domain names, 58 
child, selecting, 49-50 


different internal/external 
names, 66-68 
resolving external access, 
67-68 
resolving internal access, 
66-67 
FQDN, 21-22 
parent 
registering, 49 
selecting, 49 
registering, 69-70 
reserving, 69-70 
single internal/external name, 
60-65 
allowing external access, 
61-65 
preventing external access, 
60 


domain namespace 
defined, 256 
domains, 20 
root, 20 
subdomains, 20 
top-level, 20-21 
nodes, 20 


domain registration, 240-241 
domain trees, forests, 177 


domain trees network 
structure, 176-177 


domains 
client/server networking, 
175-176 
defined, 256 
domain controllers, 176 
domain namespace, 20 
root, 20 
subdomains, 20 
top-level, 20-21 
root, defined, 259 
top-level, 110 
COM, 21 
defined, 259 
EDU, 21 
GOV, 21 
INT, 21 
MIL, 21 
NET, 21 
ORG, 21 
XX, 21 
Windows 2000 networking, 
175-176 


down-level clients 
defined, 147 
DNS resource records, 
dynamic registration, 
148-149 
draft standard RFC, defined, 
256 


drafts (Internet), defined, 257 
Dynamic DNS (RFC 2782), 180 


Dynamic Host Configuration 
Protocol. See DHCP 


dynamic registration (DNS 
resource records), down- 
level clients, 148-149 


Dynamic Update, 6 
process, 180-181 
RFC 2136, 123, 180 


secure dynamic updates, 6 


dynamic updates 
ACLs, securing, 142 
Active Directory integrated 
name servers, 96 
DNS, 119-121 
multimaster update model, 
212 
enabling, 46 
nonsecured, RFC 2136, 181 
securing, 144-147 
troubleshooting, 234-236 
Windows NT 4.0 DHCP 
servers, 147 
zones, 51 


E 


EDU top-level domain, 21 


enabling 
debug logging options, DNS, 
218 


dynamic updates, 46 
entries, orphan, 191 


events (DNS server event log), 
configuring, 190 


experimental RFCs, 10 
defined, 256 


expire interval, 117 
expire values, 205 


external names, 57 
different internal/external 
names, 66-68 
resolving external access, 
67-68 
resolving internal access, 
66-67 
single internal/external name, 
60-65 
allowing external access, 
60-65 
preventing external access, 
60 


IANA (Internet Assigned Numbers Authority) 265 


F 
fields 


resource records, 154 
SRV resource records, 
107-108, 165-167 
top-level resource records, 153 
file servers, memory, 53 
files 
cache.dns, 83, 109 
.cap, 130 
DNS debug log, viewing, 218 
hints, recursive lookups, 109 
HOSTS, 5 
defined, 257 
Netlogon.dns 
managing DNS, 252 
registering SRV resource 
records, 252-253 
zone database files, 50 
zone.dns, 206 
filters, configuring static, 162 
firewalls 
AD, balancing internal/ 
external access, 59 
allowing external access, 
61-63, 67 
zones, separating, 60 
flags, 114 
flushing client resolver cache 
(ipconfig command), 250-251 
forests, domain trees, 177 
formats (IP v6 addresses), 
157-158 


formatting resource records, 
154 


forward lookup Active 
Directory Integrated Zone, 
35 


forward lookup resource 
records, 180-181 


. forward lookup zones, 


defined, 256 


forwarders, caching-only 
name servers, 93 


FQDN (fully qualified domain 
name), 21-22 
defined, 256 


fall packets debug logging 
options, 218 
full zone transfer (AXFR), 51, 
113 
defined, 256 
secondary name servers, 90 


fully qualified domain name. 
See FQDN 


functions, DNS console, 100 
FYI (informational) RFCs, 10 


G 


global catalogs, object 
indexes, 178 


glue records, 119 
GOV top-level domain, 21 


GSS Algorithm for TSIG 
(ETF), 180 


H 


help 

IETF drafts, 14-15 

RFCs, 9 
categories, 9-10 
stages, 10-11 
subseries, 10 
Windows 2000 DNS, 6, 

11-14 


hierarchical structure (DNS), 
19 


HINFO (Host Information) 
resource records, 167 


hints, root, 

modifying, 110 

recursive lookups, 109-111 
historic RFCs, 9 

defined, 256 


history, Internet, 5 


Host (A) resource records, 
103-104, 135, 155 
adding, 156 
DHCP clients, updating, 127 
registering, 133, 156 
unregistering, 132-134 
updating, 138-141 


Host Information. See HINFO 


HOSTS files, 5 
defined, 257 


I-J 


IAB (Internet Architecture 
Board), 8 
defined, 257 
Web sites, 8 


IANA (Internet Assigned 
Numbers Authority), 9 
defined, 257 
registering domain names, 49 
Web site, 9, 21, 49 


266 ICANN (Internet Corporation for Assigned Names and Numbers) 


ICANN (Internet Corporation 
for Assigned Names and 
Numbers) 

registering domain names, 49, 
69 
Web site, 49, 69 


ICMP (Internet Control 
Message Protocol), 113 


identifying query responses, 
nslookup command, 245-247 
IESG (Internet Engineering 
Steering Group), 9 
defined, 257 
RFC stages, 10-11 


IETF (Internet Engineering 
Task Force), 8 
defined, 257 
drafts, 14-15 
GSS Algorithm for TSIG, 180 
Web site, 8 


implementing 
DNS servers 
advantages, 200 
disadvantages, 200 
multiple DNS servers 
advantages, 201 
disadvantages, 201 


in-addr.arpa standard. 
primary zones, 34 
defined, 257 


incremental zone transfer. See 


indexes (objects), global 
catalogs, 178 


informational (FYI) RFCs, 10 
defined, 257 


installation 

Active Directory integrated 
name servers, 94-97 

Add/Remove Programs, 80 

caching-only name servers, 
92-93 

checking TCP/IP settings, 
74-75 

DCPROMO.exe command, 
81-83 

DNS service, 40 

during Windows 2000 
installation, 76 

methods, 76 

primary name servers, 87-88 

process, 75 

root name servers, 83-86 

with proxy servers, 84 

secondary name servers, 89, 
91 

starting, 74-76 


verifying, 78 
Windows 2000 Configure Your 
Server Wizard, 76-80 


instances (Performance tool), 
194 


INT top-level domain, 21 


Integrated Services Digital 
Network. See ISDN 


internal names, 57 
different internal/external 
names 
resolving external access, 
67-68 
resolving internal access, 
66-67 
single internal/external name 
allowing external access, 
60-65 
preventing external access, 
60 


Internet 
AD, internal/external access, 
59 

components 
IP transport protocol, 18 
networks, 18 
routers, 18 

DNS, 18-19 
domain registration, 

240-241 
history, 5 
root hints, 83 


Internet Architecture Board. 
See IAB 


Internet Assigned Numbers 
Authority. See IANA 


Internet Control Message 
Protocol. See ICMP 


Internet Corporation for 
Assigned Names and 
Numbers. See ICANN 


Internet Engineering Steering 
Group. See IESG 


Internet Engineering Task 
Force. See IETF 


Internet protocol. See IP 


Internet Protocol Security. 
See IPSec 


Internet protocol version 6. 
See IPV6, 


Internet Research Task Force. 
See IRTF 


Internet Root Servers, 109 


Internet Service Providers. 
See ISPs 


Internet Society. See ISOC 


Internet Standard RFCs, 
defined, 257 


Internet-Drafts, defined, 257 


interoperability (Windows 
2000 DNS), 56 

AD integrated zones, 56 
benefits, 238 
BIND, 56, 68, 239-240 
options, 56 
troubleshooting, 239-241 
Windows NT 4.0, 56 
WINS lookup, 241 


intervals 
expire, 117 
refresh, 117 
retry, 117 
IP (Internet protocol) 
defined, 258 


Internet components, 18 


IP v6 (Internet protocol 
version 6), 23 

addresses 
anycast, 156 
formats, 157-158 
multicast, 157 
unicast, 156 

defined, 258 

Web site, 156-158 


ipconfig command, 102, 225 
client resolver cache 
displaying, 248-249 
flushing, 250-251 
DNS, troubleshooting, 247-251 
DNS client registrations, 
renewing, 247-248 


IPSec (Internet Protocol 
Security) Windows 2000, 
securing, 210-211 


IRTF (Internet Research Task 
Force) 
defined, 257 
Web site, 9 


ISDN (Integrated Services 


Digital Network) resource 
records, 169 


ISO Web site, 21 

ISOC (Internet Society), 257 
Web site, 8 

Internet history, 5 
ISPS (internet Service 
Providers), 18 

iterative queries, 27, 93 

defined, 258 


name servers, 27 
performing, 28-29 


IXFR (incremental zone 
transfers), 51, 113, 206 
defined, 257 
secondary name servers, 90 
support, 7 


K 


KDC (Key Distribution 
Center), Kerberos V5, 210 
Kerberos V5 
authentication process, 210 
KDC, 210 
TGS, 210 
Windows 2000, securing, 
208-210 


Key Distribution Center, 210 


L 


LANs (local area networks), 
routers, 18 


LDAP (Lightweight Directory 
Access Protocol), AD struc- 
ture, 176 


listings, name servers, 37 
lists (notify) 
configuring, 115 
creating, 115 
load balancing, 203-204 
load sharing, 203 
local area networks. See LANs 
local roots, 112 


Local Security Authority. See 
LSA 


local security policy security 
subsystem, 209 


localized queries (DNS 
servers), testing, 217 


locating 
computers 
DNS, 17 
WINS service, 17 
servers, 55 


logging DNS performance 
data, 195-197 
looking up TCP/IP properties, 
124 
lookups 
recursive, hint files, 109-111 
reverse, PTR resource records, 
163 
LSA (Local Security 
Authority) security 
subsystem, 209 


M 


Mail Exchanger. See MX 
mail group. See MG 
mailbox domain name. See 


mailbox mail list information. 
See MINFO 

mailbox renamed. See MR 

managing 
DNS, Netlogon.dns file, 252 
DNS servers, dnscmd com- 

mand line, 221-222, 251-252 

resource records, 103-109 


master name servers. See also 
primary name servers, 36-37 
defined, 258 


MB (mailbox domain name) 
resource records, 169 


memory, servers 
application servers, 53 
configuration issues, 53 
domain controller, 53 
file servers, 53 
planning, 53 
print servers, 53 
Web, 53 


messages (NOTIFY), 
characteristics, 114 


MG (mail group) resource 
records, 170 

Microsoft Management 
Console. See MMC 

Microsoft options, 150 


Microsoft Windows 98 options, 
150 

Microsoft Windows 2000 

options, 150 

migrating servers to Windows 
2000 DNS, 55 

MIL top-level domain, 21 


MINFO (mailbox mail list 
information) resource 
records, 170 


MMC (Microsoft Management 
Console), defined, 258 
modifying 
ACL 
directory integrated zones, 


resource records, 213 
SOA resource records, 205-206 


MR (mailbox renamed) 
resource records, 170 


multicast IP v6 addresses, 157 


names 267 


multimaster update model 
(DNS), dynamic updates, 212 


MX (Mail Exchanger) 
resource records, 104-106, 
160-162 

configuring, 162 


N 


name resolution 
caching, 29 
DNS, 17 
performing, 29 


Name Server. See NS resource 
records 


name servers 
adding, 201-204 
cache-only, 204 
authoritative, 23 
caching-only, 35, 38 
creating, 38 
defined, 256 
iterative queries, 27 
listing, 37 
master, 35-37 
defined, 258 
primary, 36 
defined, 258 
resource records (TTL), 24-25 
secondary, defined, 259 
tasks, 23 
zones, 23-26 
resource records, 23 


names 
AD (Active Directory) 
balancing internal / 
external access, 59 
previously registered 
domain names, 57 
private domain names, 
58-59 
selecting, 50, 57 
subdomains of registered 
domain names, 58 
child names, selecting, 49-50 
different internal/external 
names, 66-68 
resolving external access, 
67-68 
resolving internal access, 
66-67 
domain 
FQDN, 21-22 
registering, 69-70 
reserving, 69-70 
external, 57 
internal, 57 
parent domain names 
registering, 49 
selecting, 49 


268 names 


planning, 48, 57 
single internal/external name, 
60-65 
allowing external access, 
61-65 
preventing external access, 
60 


Unicode support, 7 
zones, types, 51 


namespace (domain), defined, 
256 


nbtstat command, 226 


Net Logon service, stopping, 
183 


NET top-level domain, 21 


Netlogon.dns file 
DNS, managing, 252 
SRV resource records, 
registering, 252-253 


netstat command, parameters, 
226 


Network Monitor capture 
(.cap), 133 


Network monitor tools, 203 


Network Solutions, Inc. See 
NSI 


network subsystems, planning 
servers, 54 


networks 
client/server domains, 175-176 
Internet components, 18 
peer-to-peer, workgroups, 174 
resources, accessing, 174 
structures, domain trees, 
176-177 
traffic, DNS planning 
considerations, 51 
Windows 2000 
domains, 175-176 
schema, 178 
workgroups, 174 
New Zone command (Action 
menu), 87-90 
New Zone Wizard, 36, 42 
primary name server 
installation, 87 
secondary name server 
installation, 90-91 
no-refresh interval, automatic 
scavenging, 192 
nodes 
defined, 258 
domain namespace, 20 
Non-Active Directory-aware 
clients, 45 


nonsecure 
dynamic updates, RFC 2136, 
181 
zone information updates, 186 


notify DNS, 212 
configuring, 112-113 
process, 113-114 
notify debug logging options, 
218 
notify list 
configuring, 115 
creating, 115 


NOTIFY message, 
characteristics, 114 


NS (Name Server) resource 
records, 36 
adding, 119 


NSI (Network Solutions, Inc) 
registering domain names, 49, 
69 


Web site, 49, 69 


nslookup command, 161-166, 
208, 220 
DNS, troubleshooting, 243-247 
DNS registrations, verifying, 
244-245 
DNS server responsiveness, 
verifying, 243 
parameters, 221 
computer-to-find, 221 
-option, 221 
server, 221 
query responses, identifying, 
245-247 
subcommands, 221 


NSLOOKUP command-line 
utility, 100-101 


O 


objects 
indexes, global catalogs, 178 
Performance tool, 193 
Windows 2000 networks 
schema, 178 


obtaining TCP/IP addresses 
from DHCP client, 135 


opening DHCP management 
console, 127 
options 
Microsoft, 150 
Microsoft Windows 98 options, 
150 
Microsoft Windows 2000, 150 
standard DHCP, 150 
tracert command, 224 


ORG top-level domain, 21 


orphan entries, 191 


ownership, resource records, 
128-129, 140-142, 188 


P 


parameters 
configuration, TCP/IP 
settings, 125-126 

netstat command, 226 

nslookup, 221 
computer-to-find, 221 
-option, 221 
server, 221 

ping command, 223-224 


parent domain names 
registering, 49 
selecting, 49 


peer-to-peer networks, 
workgroups, 174 


performance servers, 
planning, 52 


Performance Monitor tools, 
203 


Performance tool, 193-194 
counters, 193 
instances, 194 
objects, 193 


performing 
controlled shutdowns (DHCP 
clients), 129-130 
iterative queries, 28-29 
name resolution, 29 


permissions, changing, 214 


ping command, 223 
parameters, 223-224 


PKI (Public Key 
Infrastructure), securing 
Windows 2000, 208 

planning 

DNS, 47 
checklist, 47-48 
communication issues, 47 
names, 48, 57 
reverse lookup zones, 52 
traffic considerations, 51 
zones, 50-52 

DNS deployment, 198 

root name servers, 83-84 

servers, 52 
capacity, 54-55 
disk subsystems, 54 
memory, 53 
networks subsystems, 54 
number needed, 55 
performance issues, 52 
placement, 55 


processors, 53 
Windows 2000 minimum 
requirements, 53 


pointer. See PTR 


primary name servers, 36, 117 
defined, 258 
installation, 87-88 
New Zone Wizard, 87-88 
SOA resource records, 89-90 
standard primary zones, 87 


primary zones, 51 
creating, 36 
standard, primary name 
servers, 87 


print servers, memory, 53 


processors, planning servers, 
53 


properties (TCP/IP), looking 
up, 124 


proposed standard RFC, 
defined, 258 


protocols 

DHCP, 6, 123 

Dynamic Update Protocol, 123 
Internet, defined, 258 
Internet version 6, 23 

defined, 258 
Lightweight Directory Access, 
176 


proxy servers 
AD (Active Directory), balanc- 
ing internal/external access, 
59 
allowing external access, 
64-68 
securing external access, 63 


PTR (pointer) resource 
records, 106-107, 137, 163 

adding, 163-165 
defined, 258 
DHCP servers, updating, 127 
registering, 133, 149 
reverse lookups, 163 
unregistering, 132, 134 
updating, 138, 141 


Public Key Infrastructure. See 
PKI 


queries oo 
caching-only name servers, 93 
defaults, 93 
identification, 114 
iterative, 27, 93, 258 

performing, 28-29 


replicating zones (Active Directory integrated name servers) 


localized, DNS servers, 217 
recursive, 26-27, 93 
defined, 258 
DNS servers, 217 
troubleshooting, 232 
resolvers, 26-27 
reverse lookup, 52 
query debug logging options, 
218 
query responses (nslookup 
command), identifying, 
245-247 


questions debug logging 
options, 218 


R 


RAS clients (Remote Access 


Server), 141 
updating resource records, 141 


receive debug logging 
options, 218 


records 
A, defined, 255 
glue, 119 
resource, 23-25 
AAAA, 156, 158 
ACL, 213 
adding, 103, 106-107, 183 
AFSDB, 168-169 
classes, 154 
CNAME, 104, 159 
defined, 258 
deleting, 182, 188 
dynamic registration, 
148-149 
fields, 154 
formatting, 154 
forward lookup, 180-181 
HINFO, 167 
Host (A), 103-104, 135, 
155-156 
ISDN, 169 
managing, 103-104, 
106-107, 109 
MB, 169 
MG, 170 
MINFO, 170 
MR, 170 
MX, 104-106, 160-162 
NA, 119 
ownership, 128-129, 
140-142, 188 
PTR (pointer), 106-107, 
137, 163-165, 258 
registering, 133, 149, 183 
registering with DHCP, 124 
reverse lookup, 180-181 
RP, 171 
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RT, 171 

scavenging, 192-193 

security, 181 

SOA, 116-118, 205-206, 259 

SRV, 107-109, 165-167, 
173, 182-188, 259 

TKEY, 145 

top-level fields, 153 

TTL, 132, 203-205 

types, 154 

unregistering, 132-134 

updating, 127, 138, 141, 
188 

values, 154 

WKS, 168 

X.25, 171-172 


recursive lookups, hint files, 
109-111 


recursive queries, 26-27, 93 
defined, 258 
DNS servers, testing, 217 
troubleshooting, 232 


refresh interval, 117 
automatic scavenging, 192 


refresh value, 205 


refreshing SRV resource 
records, 183 


registering 
DNS names (DHCP server), 
142 
domains (DNS), 240-241 
host (A) resource records, 138, 
156 
names 
domain, 69-70 
parent domain names, 49 
PTR resource records, 133, 
149 
resource records, 183 
DHCP, 124 
reverse lookup zones, 70 
SRV resource records 
(Netlogon.dns file), 252-253 


registration, dynamic (down- 
level clients), 148-149 


releasing TCP/IP address 
(DHCP client), 132 


Remote Access Server. See 


RAS 
removing root servers, 110 


renewing 
DNS client registrations 
(ipconfig command), 247-248 
TCP/IP addresses (DHCP 
client), 132 
replicating zones (Active 


Directory integrated name 
servers), 96 


270 request for comment 


request for comment. See RFC 


reserving domain names, 
69-70 


resolution, name 
caching, 29 
performing, 29 


resolvers 
client, 43 
client computers, 26 
defined, 258 
queries, 26-27 


resource records 
AAAA, 156-158 
ACL, modifying, 213 
adding, 103-107, 183 
AFSDB, 168-169 
classes, 154 
CNAME, 104, 159 
defined, 258 
deleting, 182, 188 
DHCP, registering, 124 
dynamic registration, down- 
level clients, 148-149 
fields, 154, 167 
formatting, 154 
forward lookup, 180-181 
HINFO, 167 
Host (A), 103-104, 135, 155 
adding, 156 
registering, 133, 156 
unregistering, 134 
updating, 127, 138, 141 
ISDN, 169 
managing, 103-107, 109 
MB, 169 
MG, 170 
MINFO, 170 
MR, 170 
MX, 104-106, 160-162 
configuring, 162 
NA, adding, 119 
name server (TTL), 24-25 
NS, 36 
orphan entries, 191 
ownership, 128-129, 140-142, 
188 
PTR, 106-107, 137, 163 
adding, 163-165 
registering, 133, 149 
unregistering, 132, 134 
updating, 127, 138, 141 
RAS clients, updating, 141 
registering, 183 
reverse lookup, 180-181 
RP, 171 
RT, 171 
scavenging, 192-193 
security, 181 
SOA, 36 


configuring, 116-118 
defined, 259 
modifying, 205-206 
SRV, 107-109, 165-166, 173, 
182-183 
defined, 259 
fields, 107-108 
refreshing, 183 
registering, 252-253 
viewing, 183 
TKEY, 145 
top-level fields, 153 
TTL, 132 
changing, 205 
types, 154 
updating, 188 


X.25, 171-172 
zones, 23 


resources (networks), 
accessing, 174 


responses (query), identify- 
ing, 245-247 


responsible person. See RP 


responsiveness (DNS servers), 


verifying, 243 
retry interval, 117 


reverse lookup Active 
Directory Integrated Zone, 
35, 39 


reverse lookup queries, 52 


reverse lookup resource 
records, 163, 180-181 


reverse lookup zones 
defined, 258 
planning, 52 
registering, 70 


RFCs (request for 
comments), 9 
952 Web site, 22 
1034 Web site, 27 
1035 Web site, 23, 27 
1123 Web site, 22 
1480 Web site, 21 
1591 Web site, 21 
2136 
Dynamic Update, 180 
Dynamic Update Protocol, 
123 
nonsecured dynamic 
updates, 181 
Web site, 26 
2181 Web site, 22 


2782 
Dynamic DNS, 180 
SRV resource record, 
182-183 
Web site, 23 
categories, 9-10 
defined, 258 
draft standard, defined, 256 
experimental, defined, 256 
historic, defined, 256 
informational, defined, 257 
Internet standard, defined, 
257 
proposed standard, defined, 
258 
stages, 10-11 
STD, 259 
subseries, 10 
Web site, 158 
Window 2000 DNS, 6, 11-14 


root domains 
defined, 259 
domain namespace, 20 


root hints 


modifying, 110 


recursive lookups, 111 


root name servers 

adding, 110 

DNS Server Configuration 
Wizard, 84-86 

installation, 83-86 

planning, 83-84 

with proxy servers, 84 

removing, 110 

round robin, configuring, 203 


root zone, 111 
roots, local, 112 


round robin root servers, 
configuring, 203 


Route Through. See RT 


routers 
Internet components, 18 
ISPs, 18 
LANs, 18 
WANs, 18 


RP (responsible person) 
resource records, 117, 171 


RT (Route Through) resource 
records, 171 


S 


scavenging 
automatic 
configuring, 191-192 
no-refresh interval, 192 
resource records, 192-193 
zones, 192 


schema, Windows 2000 net- 
work objects, 178 


secondary name server (New 
Zone Wizard), 90-91 


secondary name servers 
benefits, 89 
defined, 259 
installation, 89, 91 
zone transfers, 89-90 


secondary zone data, 
improving, 229 


secondary zones, 51 
creating, 36-37 


secure dynamic updates, 6, 
185-186 


secured zone information 
updates, 186 


securing 

DNS, 185 

dynamic updates, 144-147 
ACLs, 142 

Windows 2000, 208 
IPSec, 210 
Kerberos, 208 
PKI, 208 


security 
BIND issues, 68 
defined, 208 
DHCP servers, 216 
firewalls 
allowing external access, 
61-63, 67 
balancing internal / 
external access, 59 
separating zones, 60 
proxy servers 
allowing external access, 
64-68 
balancing internal / 
external access, 59 
securing external access, 63 
resource records, 181 
standard zone storage model, 
211-212 


security subsystem (Windows 
2000) 
local security policy, 209 
LSA, 209 


security tab, viewing, 137 


selecting 
AD (Active Directory) names, 
50, 57 

previously registered 
domain names, 57 

private domain names, 
58-59 

subdomains of registered 
domain names, 58 


child names, 49-50 
debug logging options, DNS, 
218 


parent domain names, 49 
servers, number needed, 55 


send debug logging options, 
218 


separating zones (firewalls), 
60 


serial numbers, 116 


server event log (DNS) 
configuring events, 190 
viewing severity, 189-190 
server nslookup parameter, 
221 


server responsiveness (DNS) 
(nslookup command), 
verifying, 243 

server settings, configuring 


zone information updates, 
187 


server system event logs 
(DNS), viewing, 219 


server-side caching, 29 


servers 
Active Directory integrated 
name 
compatibility issues, 97 
dynamic updates, 96 
installation, 94-97 
zones, 95-96 
application, memory, 53 
authorative, 119 
caching-only name 
benefits, 92-93 
forwarders, 93 
installation, 92-93 
queries, 93 
zones, 92 
capacity, planning, 54-55 
DHCP 
adding, 216 
Domain Controller, 142 
registering DNS names, 
142 
security, 216 
updating DHCP clients, 
134, 138-140 
updating DNS, 138-140 
updating PTR resource 
records, 127 
disk subsystems, planning, 54 
DNS, 200 
Dnsemd, 221-222 
implementing, 200 
implementing multiple, 201 
localized queries, 217 
recursive queries, 217 


servers 241 


supporting AD, 239 
transferring zones, 238 
troubleshooting, 230-233 
updating, 128 
verification servers, 217 
domain controllers, 53 
file, memory, 53 
master name, defined, 258 
memory configuration issues, 
53 
migrating to Windows 2000 
DNS, 55 
name 
adding, 201-204 
authoritative, 23 
caching-only, 35, 38, 256 
iterative queries, 27 
listing, 37 
master, 35, 37 
primary, 36 
resource records, 24-25 
tasks, 23 
zones, 23-26 
network subsystems, 
planning, 54 
planning, 52 
memory, 53 
number needed, 55 
performance issues, 52 
placement, 55 
processors, 53 
Windows 2000 minimum 
requirements, 53 
primary name, 117 
defined, 258 
installation, 87-88 
New Zone Wizard, 87-88 
SOA resource records, 
89-90 
standard primary zones, 87 
print, memory, 53 
proxy 
allowing external access, 
64-68 
securing external access, 63 
queries 
defaults, 93 
iterative, 93 
recursive, 93 
root name 
adding, 110 
configuring round robin, 


DNS Configuration 
Wizard, 84-86 
installation, 83-86 
planning, 83-84 
proxy servers, 84 
removing, 110 
secondary name 
benefits, 89 
defined, 259 


272 servers 


installation, 89-91 
New Zone Wizard, 90-91 
zone transfers, 89-90 
Web, memory, 53 
Windows NT 4.0 DHCP, 
dynamic updates, 147 


service (DNS) 
configuring, 41 
installing, 40 
service location resource 
records. See SRV 


services 
DNS, 17 
WINS (Windows NT 4.0), 17 


settings 
clients, configuring, 186 
servers, configuring, 187 
TCP/IP, configuration 
parameters, 125-126 


severity, DNS server event 
log, viewing, 189-190 


sharing loads, 203 


shutdowns (controlled), 
performing, 129-130 


Simple Mail Transfer 
Protocol. See SMTP 


sites. See Web sites 


slave servers. See secondary 
name servers 


SMTP (Simple Mail Transfer 
Protocol), CA, 212 


SOA (Start of Authority) 
resource records, 36, 89-90 
configuring, 116-118 
defined, 259 
modifying, 205-206 


SRV (service location) 
resource records, 107-109, 
165, 173 

defined, 259 
fields, 107-108, 165-167 
Netlogon.dns file, registering, 
252-523 
refreshing, 183 
RFC 2782, 182 
viewing, 183 
standard options (DHCP), 150 


standard primary zones, 34 
defined, 259 
primary name servers, 87 


standard secondary zones, 34 
defined, 259 


standard track (STD) RFCs, 9 
standard track. See STD 


standard zone storage model, 
security, 211-212 


standard zones, 33 
in-addr.arpa, 34 
standard primary, 34 
standard secondary, 34 


standards 

IETF drafts, 14-15 

RFCs, 9 
categories, 9-10 
stages, 10-11 
subseries, 10 
Windows 2000 DNS, 6, 

11-14 


Start of Authority (SOA) 
resource records. See SOA 


starting installation, 74-76 
static filters, configuring, 162 


statically configured Windows 
2000 clients, 140-141 


STD (standard track) RFCs, 9 
defined, 259 


stopping Net Logon service, 
183 


structures 
hierarchical, DNS, 19 
networks, domain trees, 
176-177 


subdomains (domain name 
space), 20 


subsystem security (Windows 
2000), 209 


supporting AD (DNS servers), 
239 


T 


tabs, security, viewing, 137 
tasks, name servers, 23 


TCP (Transmission Control 
Protocol), 113 
debug logging options, 218 
TCP/IP (Transmission Control 
Protocol/Internet Protocol) 
addresses (DHCP client) 
obtaining, 135 
releasing, 132 
renewing, 132 
dialog box, checking TCP/IP 
settings, 74-76 
settings 
checking prior to installa- 
tion, 74-75 
configuration parameters, 
125-126 
properties, looking up, 124 


testing 
DNS servers 
localized queries, 217 
recursive queries, 217 
verification (DNS servers), 217 


TGS (ticket-granting service), 
Kerberos V5, 210 


time to live. See TTL, 24-25, 
205, 259 


TKEY resource record, 145 


tools 
Network monitor, 203 
Performance, 193-194 
counters, 193 
instances, 194 
objects, 193 
Performance Monitor, 203 


top-level domains, 20-21, 110 
COM, 21 
defined, 259 
EDU, 21 
GOV, 21 
INT, 21 
MIL, 21 
NET, 21 
ORG, 21 
XX, 21 


top-level fields (resource 
records), 153 


tracert (Trace Route) 
command, 224 
options, 224 
traffic (networks), 51 
DNS planning 
considerations, 51 


transferring zones, 204 
to Active Directory integrated 
zones, 185 
DNS servers, 238 
incremental, 206 


Transmission Control 
Protocol. See TCP 


troubleshooting 
DNS, 208 
ipconfig command, 247-251 
nslookup command, 
243-247 
DNS clients, 22'7-230 
DNS servers, 2380-233 
DNS zones, 236-238 
dynamic updates, 234-236 
interoperability, 239-241 
recursive queries, 232 
TTL (time to live) resource 
records, 118, 132, 203 
changing, 205 
defined, 259 
name servers, 24-25 


U 


UDP (User Datagram 
Protocol), 113 
debug logging options, 218 
domain clients, 175 


users 
unicast IP v6 addresses, 156 
Unicode (DNS support), 7 


unregistering 
host (A) resource records, 
132-134 
PTR resource records, 132-134 


se ra debug logging options, 


update model (multimaster), 
212 


update security (default), 
Windows 2000, securing, 215 


updates 
dynamic 
Active Directory integrated 
name servers, 96 
DNS, 119-121 
multimaster update model, 
212 
securing, 142-147 
troubleshooting, 234-236 
Windows NT 4.0 DHCP 
servers, 147 
secure, 186 


UpdateSecurityLevel setting, 
187 


updating 
DHCP clients with DHCP 
servers, 134, 138-140 
DNS 
DHCP, 123-126 
with DHCP servers, 138, 
140 
DNS server (DHCP configura- 
tion options), 128 
host (A) resource records, 
138-141 
DHCP clients, 127 
PTR resource records, 138-141 
DHCP servers, 127 
resource records, 188 
RAS client, 141 
zone information, 183-186 
configuring clients, 186 
configuring servers, 187 
nonsecure updates, 186 
secured updates, 186 


utilities (command line) 
Dnscmd, 102 
Ipconfig, 102 
NSLOOKUP, 100-101 


WKS (Well Known Services) resource records 213 


V 


values 
expire, 205 
refresh, 205 
resource records, 154 


verification testing (DNS 
servers), 217 
verifying 
DNS registrations (nslookup 
command), 244-245 
DNS server responsiveness 
(nslookup command), 243 
installation, 78 
viewing 
debug log file (DNS), 218 
DNS counters, 194 
DNS performance data, 
195-197 
DNS server event log severity, 
189-190 
DNS server side event logs, 
219 
resource records, 38 
security tab, 137 
SRV resource record, 183 
zones, 38 


W 


WANs (wide area networks), 


routers, 18 
Web servers, memory, 53 


Web sites 
IANA, 21 
IP v6, 156-158 
ISO, 21 
RFC 952, 22 
RFC 1034, 27 
RFC 1035, 23, 27 
RFC 1123, 22 
RFC 1591 , 21 
RFC 2136, 26 
RFC 2181, 22 
RFC 2782, 23 
RFCs, 21, 158 


Well Known Services. See 
WKS 


wide area networks. See 
WANs 


Windows 9x, clients, 45 


Windows 2000 
booting process, 178 
clients, statically configured, 
44, 140-141 
DNS, 6-7 
BIND, 15 
IETF drafts, 14-15 
RFC compliance, 6, 11-14 


Windows NT 4.0 
comparison, 6 
installation, DNS installation, 
76 
IPSec, securing, 210 
Kerberos, securing, 208 
networking 
domains, 175-176 
object schema, 178 
workgroups, 174 
options, 150 
PKI, securing, 208 
securing, 208 
server requirements, 53 


Windows 2000 Configure Your 
Server Wizard (DNS 
installation), 76-80 


Windows Internet Name 
Service. See WINS 


Windows NT 4.0 
clients, 44 
Active Directory, 151 
DHCP servers, dynamic 
updates, 147 
migrating to Windows 2000 
DNS, 55 
Windows 2000 DNS 
comparison, 6 
Windows 2000 DNS 
interoperability, 56 
WINS service, 17 
zones, 51 


WINS (Windows Internet 
Name Service) 

defined, 259 

lookup, interoperability, 241 

query responses, identifying, 
245-247 

service (Windows NT 4.0), 
locating computers, 17 


wizards 
Active Directory, domain 
controllers, 178 
Active Directory Installation 
creating domain con- 
trollers, 179 
DNS installation, 81-82 
DNS Server Configuration 
Wizard, 41 
root name server 
installation, 84-86 
New Zone Wizard, 36, 42 
primary name server 
installation, 87 
secondary name server 
installation, 90-91 
Windows 2000 Configure Your 
Server Wizard, DNS instal- 
lation, 76-80 


WKS (Well Known Services) 
resource records, 168 


274 workgroups 


workgroups 
peer-to-peer networks, 174 
Windows 2000 networking, 
174 


write through debug logging 
options, 218 


X-Z 


X.25 resource records, 171-172 


XX top-level domain, 21 


zone information updates 
client settings, configuring, 
186 
server settings, configuring, 
187 


zone transfers, 204 
incremental, 206 
secondary name servers, 89-90 


zone.dns file, 206 


zones, 50 
Active Directory Integrated, 
34 


ACL, 214 
creating, 38 
defined, 255 
DNS interoperability, 56 
forward lookup zone, 35 
reverse lookup zone, 35, 39 
transferring to, 185 
zone replication, 95-96 
adding, 52 
caching-only name servers, 92 
creating, 42 
defined, 259 
DNS 
ACL, 213 
troubleshooting, 236-238 


DNS servers, transferring, 238 


dynamic updates, 51 
forward lookup, defined, 256 
full zone transfer (AXFR), 51 
in-addr.arpa, defined, 257 
incremental zone transfer 
(IXFR), 51 
information, updating, 
183-186 
information updates 
nonsecure, 186 
secured, 186 
name servers, 26 
resource records, 23 
planning, 50-52 
primary, 51 
creating, 36 


reverse lookup, 258 
planning, 52 
registering, 70 

root, 111 

secondary, 51 
creating, 36-37 
improving data, 229 

separating firewalls, 60 

standard, 33 
in-addr.arpa, 34 
standard primary, 34 
standard secondary, 34 

standard primary 
defined, 259 
primary name servers, 87 

standard secondary, defined, 
259 

types, 51 

viewing, 38 

Windows NT 4.0, 51 

zone database files, 50 

zone transfers, 51 


The IT site 
you asked for... 


InformIT 
n a 


InformIT is a complete online library delivering 
information, technology, reference, training, news, 
and opinion to IT professionals, students, 
and corporate users. 


Find IT Solutions Here! 


www.informit.com 


InformIT is a trademark of Macmillan USA, Inc 
Copyright © 2000 Macmillan USA, Inc 


Andy Ruth has been in the computer industry since the 1970s and 
provided support for military flight simulators, large mainframes, and | 
small PC-networked environments. Andy holds the MCT and MCSE+! 
certifications, as well as others, and has written a number of books on 
Microsoft products. He is currently working with the Windows 2000 
training curriculum as a program manager at Microsoft Corporation. 


Bob Collier helped design, implement, and manage computer 
: The Concise Guide to l networks at military organizations and is currently a senior 
technical instructor at the Advanced Computer Education Center 
MICROSOFT at Southern Methodist University. Bob is currently certified as 
® a MCSE, MCT, MCP+I, A+, and Network+, and is certified to train 
W I N D O W S 9) 0 0 0 D N S Windows 2000 courses. Bob is also involved in consulting for 
small to medium businesses specializing in network design, 
implementation, troubleshooting, and documentation skills for 
Uncommon Solutions for the Technical Professional Windows NT 4.0 BackOffice networks. 


The Concise Guide to Microsoft Windows 2000 By giving IT professionals and advanced users 
DNS provides the foundation knowledge the expert-level information they need , The 
needed to install, maintain, and troubleshoot Concise Guide to Microsoft Windows 2000 DNS 
DNS in a Windows 2000 environment. will be the book the experts rely on for their 
How the DNS service works and provides information. 
support to a Windows 2000 network are topics Some of the topics covered in this book are: 
that have not been extensively addressed for Understanding how DNS works 
network designers, administrators, and Windows 2000 Ciente And Sororis 
support personnel. This book tells you both Installing, configuring, and maintaining a DNS 
what you need to know to benefit fully from the installation 
potential that the DNS service provides Growing a DNS installation 
Windows 2000 and how it interoperates with Exploring resource records 
other DNS name servers. You will also find Securing and troubleshooting DNS 

communications 


information on the RFCs that pertain to DNS In fo Idaa 


and gain an understanding of each of them. 


ry 
COII 


$34.99 USA / $52.95 CAN / £25.50 Net UK 
ISBN 0-7897-2335-2 


Category Operating Systems | PAR A 
pen Microsoft Windows 2000 DNS | | | || 
ieee ae Advanced — Expert 

0923072559 4 91780789723352 


